Change Details

### Background FY25/26 KR 5.2 focuses on bringing API endpoints onto common infrastructure. The main aspect of that focuses on routing all traffic through a common API Gateway. To that end, the final set of endpoints that must be rerouted through the common gateway are those remaining on the historic API Gateway (aka: those documented through the [[ https://api.wikimedia.org/wiki/API_catalog | API Portal ]]). While the majority of these endpoints follow the same rate limits, the Lift Wing API is an outlier with a [[ https://api.wikimedia.org/wiki/Lift_Wing_API/Rate_limits | custom rate limit policy ]]. To complete the rerouting work, we need to be able to support higher limits for these endpoints, potentially with different thresholds based on user class. ### Conditions of acceptance [] Support 200k/hr limits for the Enterprise client (new group) [] Support 100k/hr limits for identified traffic (authenticated, known bot, WMCS) [] Evaluate and verify limits for unidentified traffic The higher limits should only apply for the lift wing endpoints. NOTE: Halley has some outstanding questions with the Machine Learning team to get a better sense of the history and context for the current limits. We also need more data about how many users are hitting existing limits, and the overlap between JWT based overrides with the defined API user classes.

### Background FY25/26 KR 5.2 focuses on bringing API endpoints onto common infrastructure. The main aspect of that focuses on routing all traffic through a common API Gateway. To that end, the final set of endpoints that must be rerouted through the common gateway are those remaining on the historic API Gateway (aka: those documented through the [[ https://api.wikimedia.org/wiki/API_catalog | API Portal ]]). While the majority of these endpoints follow the same rate limits, the Lift Wing API is an outlier with a [[ https://api.wikimedia.org/wiki/Lift_Wing_API/Rate_limits | custom rate limit policy ]]. To complete the rerouting work, we need to be able to support higher limits for these endpoints, potentially with different thresholds based on user class. ### Conditions of acceptance Update rate limits for Lift Wing to the following: * Unidentified - 50k/hr; 15/s * Browser - 50k/hr; 50/s * Authenticated - 100/hr; 100/s * WMCS - 200/hr; 200/s * Approved bot - 200/hr; 200/s * Known client - 200/hr; 200/s The higher limits should only apply for the lift wing endpoints. One enabled, pay close attention to WME traffic in particular, as they represent the current highest volume consumer.

### Background FY25/26 KR 5.2 focuses on bringing API endpoints onto common infrastructure. The main aspect of that focuses on routing all traffic through a common API Gateway. To that end, the final set of endpoints that must be rerouted through the common gateway are those remaining on the historic API Gateway (aka: those documented through the [[ https://api.wikimedia.org/wiki/API_catalog | API Portal ]]). While the majority of these endpoints follow the same rate limits, the Lift Wing API is an outlier with a [[ https://api.wikimedia.org/wiki/Lift_Wing_API/Rate_limits | custom rate limit policy ]]. To complete the rerouting work, we need to be able to support higher limits for these endpoints, potentially with different thresholds based on user class. ### Conditions of acceptance [] Support 200k/hr limits forUpdate rate limits for Lift Wing to the Enterprise client (new group)following: * Unidentified - 50k/hr; 15/s [] Support 100k/hr limits for identified traffic (authenticated, known bot,* Browser - 50k/hr; WMCS)50/s [] Evaluate and verify limits for unidentified traffic* Authenticated - 100/hr; 100/s * WMCS - 200/hr; 200/s * Approved bot - 200/hr; 200/s * Known client - 200/hr; 200/s The higher limits should only apply for the lift wing endpoints. NOTE: Halley has some outstanding questions with the Machine Learning team to get a better sense of the history and context for the current limits.One enabled, We also need more data about how many users are hitting existing limitspay close attention to WME traffic in particular, andas the overlap between JWT based overrides with the defined API user classes.y represent the current highest volume consumer.