Wikimedia APIs/Rate limits/FAQ
The page provides answers to frequently asked questions about the API Rate limits introduced in 2026.
General questions
[edit]Why is the Wikimedia Foundation introducing API rate limits?
[edit]Since 2024, we have observed a significant rise in automated traffic. As of early 2026, this now represents around 40% of page views and the majority of our most expensive traffic. Rate limits allow us to better identify who is using our APIs, helping us to ensure that developers are using the most appropriate access channels, and prioritise community members and human readers.
Are rate limits applied across all APIs and Wikimedia projects?
[edit]Request-based rate limits are global across all Wikimedia projects. They currently apply to the Action API and REST API, with the LiftWing APIs still subject to separate limits that are considerably higher. We intend to explore the feasibility of cost-based or concurrency limits for Wikidata Query Service and Wikimedia Commons Query Service over the coming months.
What’s new? Didn’t we already have rate limits in place?
[edit]MediaWiki has its own fine grained system of rate limits, which can differ between sites. These are primarily used to limit the rate at which users can edit and perform other changes. Their primary purpose is to protect against vandalism. However, they are not cross-wiki and cannot protect against the abuse of services that are not implemented in MediaWiki.
Do API rate limits apply to requests from web browsers and Gadgets?
[edit]Rate limits apply to all API requests, including those made from a web browser when a user interacts with MediaWiki. Gadgets are subject to the same rate limits as any other browser request. This means that logged in users will get significantly higher limits, helping to ensure that key workflows are not impacted.
Do rate limits apply to third-party wikis that use InstantCommons?
[edit]Yes. InstantCommons and QuickInstantCommons are subject to API rate limits for retrieving image metadata, as well as limits at the CDN for accessing image files. Site operators are requested to update to a recent version of MediaWiki and enable caching with a long TTL. This will ensure a compliant User-Agent is set and reduce the chance of hitting rate limits.
Why can’t you just block people who abuse the APIs?
[edit]In the past, abusive bots were fewer in number and easier to identify. Many modern bots operate outside of the established rules of the Internet, acting with no regard for the health of the websites they access and actively try to evade detection. We have set the default limits high enough to cover almost all usage, but need to be able to better identify the source of legitimate high volume API requests to ensure that they are not affected by attempts to block abusive traffic of unknown origin.
What should I do if I require high volume, commercial access?
[edit]The 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. Those with mission-aligned use cases can request exceptional access to the paid level at no charge.
Rate limit questions
[edit]What should I do if I start receiving rate limit errors?
[edit]Start by ensuring that you are following the best practices outlined in the documentation. If you have set a compliant User-Agent, consider authenticating your bot, running it on WMCS or, if appropriate, requesting approved bot status from the community. If none of these options are suitable, please email bot-traffic@wikimedia.org for further assistance.
Do admins or other users with extended rights get higher limits?
[edit]Limits for established users have been set sufficiently high to cover the editing and admin workflows of almost all users. New users are subject to lower rate limits until they become active contributors, which helps prevent scrapers from creating accounts to bypass limits. Community approved bots and certain global user groups like stewards are exempt from all API rate limits, to ensure that the critical role that they play in trust and safety cannot be affected.
My script is running on WMCS/Toolforge, why is it still being rate limited?
[edit]Make sure that you are sending a compliant User-Agent header with all requests, including a name for the bot and a way to contact you as its operator. Requests using a generic User-Agent may be subject to rate limits or blocked entirely, even on WMCS.
What is the best approach for single-user bots that require a high limit?
[edit]We recommend that bot operators consider authentication for all requests, especially if they are running outside WMCS. This provides the strongest form of identification, regardless of where a bot runs, and ensures that bots receive the highest level of rate limits that are available to the authenticated user. All authentication mechanisms are supported by API rate limiting, though some do require cookies to be enabled.
Is there a community process for requesting higher rate limits?
[edit]Community bots that run under a separate bot account and are used to perform repetitive tasks on a wiki, can request a bot flag as outlined in the Bot policy. A local bot flag on any wiki, or the global bot flag, will exempt the approved bot from API rate limits. We have set the rate limits for new and established user accounts at a level that should cover legitimate usage without the need to request higher limits. However, keep in mind that bots that modify content in any way are also subject to community rules and guidelines, as well as MediaWiki’s own rate limits.
Are research projects able to request higher rate limits?
[edit]We believe that the majority of research projects should find the default limits for authenticated users sufficient for their needs. Where this is not the case, it’s likely that the project should be using dumps, or running in WMCS if their research is aimed at improving the Wikimedia projects. A higher rate of access to Wikimedia Enterprise APIs can also be provided for research purposes that meet the exceptional access criteria. Researchers are encouraged to learn more about access to data for research and the Wikimedia research community.
Authentication questions
[edit]What authentication methods can I use to get higher rate limits?
[edit]All existing authentication methods are supported, including bot passwords, owner-only consumers and OAuth. Cross-wiki API requests can be authenticated using centralauthtoken. Owner-only consumers and OAuth 1.0 require clients to implement support for cookies to receive higher limits.
Why do I need to send cookies with owner-only consumers and OAuth 1.0?
[edit]As not all APIs are implemented in MediaWiki, validation of the authentication token happens in a separate API gateway. This requires tokens to be formatted as a JSON Web Token (JWT) that contains information about the session and a cryptographic signature. For methods that don’t natively use JWTs in the correct format, we support them by setting a JWT session cookie. Note that an OAuth consumer that acts on behalf of multiple users needs to use separate cookie jars for each user.
Why are OAuth 2.0 owner-only consumers not sufficient?
[edit]Owner-only consumers are convenient, but as they do not expire, they cannot be revoked in a way that the API gateway can independently enforce. For this reason, OAuth 2.0 owner-only tokens can only be used to authenticate users, not to authorize them, as access levels and available rate limits may change over time. We intend to improve support for the standard OAuth 2.0 client credentials flow, which will remove the need for cookies.
Note that cookies should only be sent with owner-only tokens. OAuth consumers that use the authorization token flow to act on behalf of multiple users should not send cookies.
What is the preferred authentication method for new applications?
[edit]For applications that act on behalf of a user, you should use OAuth 2.0. Single-user applications (“bots”) can continue to use bot passwords or owner-only tokens. We plan to add support for the OAuth 2.0 client credentials flow as a recommended alternative for bots, as it reduces security risks through the use of short-lived tokens and OAuth 2.0 has become the most widely supported standard for API authorization.
Are you going to make it easier to create new OAuth clients?
[edit]Yes. We are planning significant improvements to the on-wiki pages for creating and managing OAuth clients, including clearer terminology, a simpler registration flow and the ability to edit existing clients without re-registering them. We also intend to improve developer documentation and help ensure that commonly used community libraries support OAuth 2.0.
