<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=278964&issueIid=587887) </details> <!--IssueSummary end--> ## Context This issue tracks the evaluation and potential refactoring of two webhook rate limit feature flags: - `web_hook_event_resend_api_endpoint_rate_limit` - `web_hook_test_api_endpoint_rate_limit` ## Motivation As noted in MR !218726, these ops feature flags should be evaluated for conversion to application settings instead of remaining as long-lived feature flags. ### Suggestions from Review From @SamWord's review comments: > "I'm not really sure why this needs to be an ops flag when we could make the webhook resend API rate limit configurable in application settings" > "This flag functions the same as `web_hook_event_resend_api_endpoint_rate_limit` but for a different rate limit. I also don't see why this shouldn't be a rate limit that's configurable in application settings" ## Proposal Convert these webhook rate limit feature flags to configurable application settings, allowing administrators to adjust rate limits without requiring feature flag changes. ## Related - MR: !218726 - Refresh milestone for Import ops feature flags - Feature flag documentation: https://docs.gitlab.com/development/feature_flags/#ops-type