Wikimedia APIs/Rate limits
Requests to Wikimedia APIs are subject to rate limiting to protect Wikimedia infrastructure from overloading and to ensure fair access to resources for all clients. Rate limits apply across all sites and platforms, including requests to the Action API and REST APIs, and are enforced per user.
Rationale
API rate limits are being deployed in 2026 to ensure fair and sustainable access to Wikimedia resources. The goal is to reduce the amount of unauthenticated, automated API requests (about 33% at the end of 2025) and to prevent high-volume commercial consumers from putting undue load on our infrastructure.
Ideally, members of Wikimedia communities will not be affected by this change. They may even benefit from the fact that fewer resources are being used by commercial consumers. However, it is possible that a small number of bots and other tools which operate at a very high rate may get rate limited. To avoid being impacted by rate limits, follow the best practices below.
Best practices
To avoid being rate limited, clients should follow these best practices and the rules in the robot policy. In particular, clients should:
- include a meaningful User-Agent header that includes contact information such as an email or full URL. For example:
CoolBot/0.0 (https://example.org/coolbot/; coolbot@example.org) generic-library/0.0. For more information, see the User-Agent policy. - implement cookie support when using bot passwords or OAuth to authenticate. However, multi-user OAuth 2 apps should not send cookies.
- limit the number of concurrent requests to 3 or fewer.
- follow API-specific guidelines, such as Action API etiquette.
- respect the Retry-After header provided with a 429 Too Many Requests status code.
Community members that need a higher rate of access should:
- request the bot flag from your local wiki community. Community-approved bots get higher rate limits.
- where appropriate, consider running your bot in Toolforge or another Wikimedia Cloud Services offering.
If you require high-volume, commercial access:
- Wikimedia Enterprise APIs are available with free access for all users up to certain speed and volume limits.
- commercial rates are offered for those who require higher speed, volumes or SLA requirements.
Limits
Rate limits take into account the client's identity and level of access. Below is an overview of rate limits grouped by the type of client (caveats apply). They are enforced per-minute to help to smooth out API traffic and minimize the impact on any user that inadvertently hits a rate limit. Limits have been set at a level that is high enough to still allow for short bursts of requests.
| Group | Description | Limit (req/min) |
|---|---|---|
| Unidentified | Requests with no identifying characteristics other than IP address | 10 |
| Requests made from a web browser by an unauthenticated user | 200 | |
| User-Agent only | Unauthenticated bot requests with a compliant User-Agent header | 200 |
| Requests from third-party MediaWiki wikis (for example via InstantCommons) | 200 | |
| Authenticated | Authenticated requests from users who are new or have few edits | 200 |
| Authenticated requests from users who are established editors | 2000 | |
| Authenticated requests from users with extended global rights (e.g. stewards) | Exempt [limits 1] | |
| Authenticated requests from bots accounts with a bot flag on any wiki | Exempt [limits 1] | |
| Wikimedia Cloud Services (WMCS) | Server-side requests from WMCS with a compliant User-Agent | Exempt [limits 1] |
| Known client | Requests from clients granted an exemption by the Wikimedia Foundation | Exempt [limits 1] |
- ↑ 1.0 1.1 1.2 1.3 Clients that are exempt from API rate limiting are still subject to operational rate limits and the Robot policy.
Action-based rate limits
In addition to limits based on client identity, actions (such as editing pages, moving pages, and uploading files) are rate limited to prevent vandalism and other harmful behaviors. Action-based limits depend on the status of the user account and on the policy of the individual wiki. For example, most Wikimedia projects limit logged-out users to eight edits per minute. To learn more about actions and specific limits, see Manual:Rate limits.
Errors
When a client exceeds its rate limit, the gateway responds with HTTP status code 429 (Too Many Requests). Other components involved in handling the request may also respond with status 429 when per-client limits are exceeded, or with status 503 (Service Unavailable) when a backend system such as a database server is overloaded.
Responses with status code 429 or 503 typically also have the Retry-After header set, indicating how long the client should wait until it retries the request. If no such header is present, clients should wait at least five seconds, or implement exponential back-off.
Caveats
Operators of API clients should be aware of the following edge cases and pitfalls:
- The limits described above do not apply to the Lift Wing API. To learn about rate limits for the Lift Wing API, see the documentation on Wikitech.
- OAuth 1 access tokens are not supported on their own by the rate limit infrastructure. Requests using OAuth 1 tokens will be treated as unauthenticated with respect to rate limiting, unless you also send cookies with the request.
- Elevated rate limits embedded directly in some older owner-only tokens are ignored by the new rate limiting infrastructure (but are still used for endpoints on api.wikimedia.org, see T409305). Going forward, rate limits will be determined by a user's current privileges, not limits assigned at the time of token creation.
- Generally, a refresh-token flow or client-credentials flow would be preferred over direct use of owner-only tokens for OAuth 2.0, but support for that is still limited (see T407987 and T412214 ). For now, clients should support session cookies to be used along with OAuth tokens. This allows the correct rate limit class to be applied.
Get help
Bot operators who are unsure how to get the access they need can contact the Wikimedia Foundation at bot-traffic
wikimedia.org.
