On Mon, 2 Mar 2026 at 19:30, Sohom Datta via Wikitech-l <[email protected]> wrote: > > Can we get exact numbers for these rate limits? "low", "medium", "high", and > "very high" aren't very useful in the context of me trying to figure out if I > should drop everything I am doing and allocate the next week to implementing > OAuth 2.0 support for my bots and other hobby projects. One thing I will say > about this change is that while I do completely understand that there is a > need to cut down bot traffic to our servers, a change that involves > rate-limiting contributor workflows, especially those who are performing > (often) load-bearing moderation tasks, does not feel like a good way forward. > Also, implementing OAuth 2.0 (and subsequently getting it approved) for > support is non-trivial, especially for "home-grown" bots. Absent any evidence > that community-run "home-grown" bots are the root of this problem, I feel > like asking them to implement such a solution is counterproductive in this > context.
We are still finalizing the exact limits, but do intend to publish exact numbers as soon as we can. To give you an idea, anonymous requests will be in the hundreds per hour, authenticated several thousand per hour. To be clear, these limits will not apply to bots running on Toolforge/WMCS, regardless of whether they use authentication. > What about bot passwords (and OAuth 1.0a, as other folks have asked)? Note > that adding OAuth 2.0 support is currently a significant burden compared to > simply providing a proper UserAgent (which was the previous policy). I don't > even know how I would implement OAuth 2.0 support for my Go bot (and random > Python script) without spending a non-trivial amount of time reviewing the > associated documentation. Bot passwords and OAuth 1.0a will work if you send cookies, as this will send a JWT we can validate in the traffic layers before requests reach MediaWiki. Whilst this is non-standard for OAuth 1.0a, it’s the best compromise we were able to implement whilst we work together on a longer term transition towards OAuth 2.0 as the preferred method for API authentication. This will include improving the processes and documentation around OAuth 2.0, but is not something that we can wait for due to the pressures on our infrastructure from increased automated traffic. >> Request the bot flag from your local wiki community > > To my knowledge, this is also not a trivial process in many communities > (e.g., enwiki). If I need to start a month-long (or more) discussion just to > retrieve (say) the data for all recently reverted edits to perform my own > analysis and/or make 1000 edits using Pywikibot, I feel like a contributor > might ask/feel: "Will it be easier to just not do this task?" This support was primarily intended as one way to ease the transition for existing tools. For most cases, the current exemption for WMCS and generous limits for authenticated traffic outside that environment should be sufficient for bots that wouldn’t otherwise need the bot flag. Operators of high-volume bots that may be impacted by this and need help finding a solution can also contact the WMF to discuss a potential exemption as a “known client”: https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits#Get_help >> Use Wikimedia Enterprise APIs for high-volume usage > > This is the part I'm extremely uncomfortable with. I feel very strongly that > community members who are contributing in mission-aligned ways should not be > asked to shift to use a closed-source, monetary contributions-gated, > out-of-date version of our own data that they have spent hours curating. I > feel this is a very clear line in the sand: community members should NOT have > to pay (i.e., buy/sign up for an Enterprise subscription) to access Wikimedia > data. If we ever end up in a scenario where a contributor feels compelled to > pay for a Wikimedia Enterprise account, we have done something seriously > wrong. (The only caveat to that statement is if we have a contributor who > founds an AI startup/Google alternative, or similar) I know that Liam has just replied to this with further detail from an Enterprise perspective, but I want to address it directly too. We are absolutely not asking community members to shift to Enterprise, though they are able to request free access for mission-aligned purposes if they want to use one of the services it offers. Indeed, these limits are being put in place in part to protect community access to existing community APIs. This pointer to Enterprise is primarily aimed at ensuring those that require what it offers in terms of commercial usage with SLAs etc are aware of it as an option that they should consider if they require high-volume access. Thanks for the questions, I will start to collect these and other questions together in an FAQ on-wiki so that they are more broadly documented. _______________________________________________ Wikitech-l mailing list -- [email protected] To unsubscribe send an email to [email protected] https://lists.wikimedia.org/postorius/lists/wikitech-l.lists.wikimedia.org/
