Talk:Wikimedia Enterprise

I'm peased to announce the 4th annual report for Wikimedia Enterprise is now published!

The financial highlights are that:

• Not only does this report show the first complete year of profitability, but even more importantly, that earned revenue has now fully repaid the initial investment in the project from previous fiscal years.
• Within four years of its launch Wikimedia Enterprise is now a net-contributor to the financial stability of the Wikimedia projects.
• The revenue has seen a 148% increase from the prior year, and represents 4% of Wikimedia Foundation’s total revenue for the period.

If, after reading the blogpost, you have any questions please leave them here below. Thank you. LWyatt (WMF) (talk) 19:18, 24 November 2025 (UTC)Reply

Thank you for publishing the report. I read it and I wondered about the amount of tax Wikimedia Enterprise had to pay. I expected this amount to be higher. So I read the explanation about taxation in a Diff Blogpost from 2023. What business activities are relevant for local and state tax. When reading the text I was not sure if it are only activities outside of the main purpose of the the tax excempt organization or all business activities. Hogü-456 (talk) 12:24, 13 December 2025 (UTC)Reply

Hello Hogu,

"Professional services" is taxable. For the benefit of anyone else reading this comment too, here is the relevant paragraph from that report:

Based on advice from our external tax advisors, the revenue derived from the API subscription itself is not taxable. By contrast, income derived from unrelated business activities may be taxable to non-profit organizations. This unrelated business income is income from a trade or business, regularly carried on, that is not substantially related to the purpose that is the basis of the organization’s tax exemption. For Wikimedia Enterprise, taxable income includes professional service revenue, net of expenses. In this context, “professional services” is the small portion of revenue Wikimedia Enterprise engineers spend consulting with customers at their request, to provide expert technical advice to a specific customer about their own systems and setup.

LWyatt (WMF) (talk) 12:38, 15 December 2025 (UTC)Reply

@LWyatt (WMF) and the rest of the team: well done! For years I was skeptical and didn't think this project would reach profitability, but this $8M year put the project in the black, and in 4 years, not a bad time to return for this project, under any standard. Glad I was wrong. Congrats! Levivich (talk) 00:26, 15 December 2025 (UTC)Reply

Thank you @Levivich for going out of your way to post this kind comment. We are - I think justifiably! - quite proud of this achievement. It is one thing to be able to make a profit (and repay the investment of donor-money), but it is also even more important IMHO that we do this in the right way - in accordance with strong Project Principles that are consistently applied. LWyatt (WMF) (talk) 13:00, 15 December 2025 (UTC)Reply

Is there a particular reason why Wikimedia Enterprise (both the public-facing site and the API) doesn't have IPv6 enabled? Especially since the public-facing site (enterprise.wikimedia.com) uses Cloudfront, and it shouldn't be difficult to enable IPv6 on that. ~2025-43587-40 (talk) 00:16, 29 December 2025 (UTC)Reply

Just a quick note to say that I’ve seen this question and will get a reply for you from my colleagues. But the WMF has a holiday shutdown period at the moment until the new year so it will be a week. LWyatt (WMF) (talk) 09:05, 29 December 2025 (UTC)Reply

Note: This question has also been asked by a different person via the team's Phabricator board. It is being triaged and can be tracked here: task T411528.

LWyatt (WMF) (talk) 13:39, 13 January 2026 (UTC)Reply

Thanks for reaching out with this question!

IPv6 support on the Enterprise API public domains was not omitted due to a technical oversight. Rather, at the time the service was designed and launched, there were no explicit requirements for IPv6 from Enterprise users, nor any requests indicating a business need for it.

Supporting IPv6 would involve non-trivial engineering and operational effort across our infrastructure. Given the lack of user demand and the associated complexity, we prioritized other features that delivered more immediate value.

That said, we continuously reassess priorities based on user needs, and IPv6 support can be reconsidered if there is sufficient demand. Please remain subscribed to this ticket which we will file in our workboard to monitor any future updates. JArguello-WMF (talk) 14:12, 26 January 2026 (UTC)Reply

Out of curiosity... what's the "non-trivial engineering and operational effort"?

Also, what about the public-facing homepage/documentation site (enterprise.wikimedia.com)? That appears to be little more than a simple website that uses Cloudfront, so turning on IPv6 for that should be a very simple change that can be done in a few clicks. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistValuesGeneral.html#DownloadDistValuesEnableIPv6 ~2026-65201-7 (talk) 03:35, 30 January 2026 (UTC)Reply

If we move forward with this, we’d implement full dual-stack support across our entire system—not just the user-facing layers.

The reason for a backend overhaul choice is: Bringing the Enterprise platform to full dual-stack would align it with the Foundation services and establish a consistent networking model across systems. This makes future service interconnectivity simpler, reduces long-term fragmentation, and positions the platform better for upcoming integrations and growth. Although this represents a larger upfront investment, it avoids divergence between platforms and helps keep the overall infrastructure cohesive.

If/when our users do request IPV6 then the priority would be to work on that for the APIs and the public-facing site would follow. Therefore, I recommend you subscribe to the Phabricator task T411528 for monitoring any future update on that topic.

Thanks again for reaching out! JArguello-WMF (talk) 14:19, 30 January 2026 (UTC)Reply

Hello all,
In the context of today's "25th Birthday" – and as first stated in today's WMF press release Wikipedia celebrates 25 years of knowledge at its best – I have the pleasure of highlighting the following:

...Over the past year, we have formalized relationships with several companies that rely on Wikimedia project data to power their applications.
Today, we are announcing Amazon, Meta, Microsoft, Mistral AI, and Perplexity for the first time as they join our roster of partners, which includes Google, Ecosia, Nomic, Pleias, ProRata, and Reef Media. All these organizations utilize Wikimedia Enterprise to integrate human-governed knowledge into their platforms at scale...

— excerpt from Wikimedia Enterprise blog Announcing New Wikimedia Enterprise Partners for Wikipedia’s 25th Birthday

This announcement is the first time we've been able to note several customers for the first time simultaneously. It is a testament to trust and confidence that these organisations have in Wikimedia - the content, the community [and this specific API service] – that they are all happy to be included together as part of today's birthday announcements.

See also:

• The Naming of customers policy - subsection of the WMF Commercial Sales and Contracts Policy
• Previous blogposts of new individual partner announcements
• The most recent annual report (covering July 2024-June 2025), highlighted earlier on this page at: #4th annual financial report

LWyatt (WMF) (talk) 11:01, 15 January 2026 (UTC)Reply

Update - News stories covering this announcement:

• Reuters - https://www.reuters.com/business/retail-consumer/wikipedia-owner-signs-microsoft-meta-ai-content-training-deals-2026-01-15/
• The Verge - https://www.theverge.com/news/862109/wikipedia-microsoft-meta-perplexity-ai-training-wikimedia-foundation
• Associated Press - https://apnews.com/article/wikipedia-internet-jimmy-wales-50e796d70152d79a2e0708846f84f6d7
• TechCrunch - https://techcrunch.com/2026/01/15/wikimedia-foundation-announces-new-ai-partnerships-with-amazon-meta-microsoft-perplexity-and-others/
• ArsTechnica - https://arstechnica.com/ai/2026/01/wikipedia-will-share-content-with-ai-firms-in-new-licensing-deals/
• Washington Post - https://www.washingtonpost.com/business/2026/01/15/wikipedia-internet-jimmy-wales/006d4da0-f1ed-11f0-a4dc-effc74cb25af_story.html
• Engadget - https://www.engadget.com/ai/wikimedia-announces-ai-partners-including-meta-and-microsoft-162834383.html
• CNBC - https://www.cnbc.com/2026/01/15/wikipedia-amazon-meta-perplexity-ai.html
• Observer - https://observer.com/2026/01/wikipedia-turns-25-ai-reckoning/
• Forbes - https://www.forbes.com/sites/johnkoetsier/2026/01/15/wikipedia-turns-25-sells-access-to-amazon-meta-microsoft-and-other-ai-giants/

-- LWyatt (WMF) (talk) 12:15, 15 January 2026 (UTC)Reply

Also The Independent: Wikipedia unveils new AI licensing deals as it marks 25th birthday—Sad to see this misrepresented as "licensing deals". I hope a correction can be encouraged.

Speaking of which, have the contracted clients undertaken any obligation to meet the "By" and "SA" requirements of our licence? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:12, 15 January 2026 (UTC)Reply

Thanks for noticing this Andy. You're quite right that it's a misrepresentation to imply that its a "licensing" deal... Some in the general public may feel that it's "a distinction without a difference" but personally I feel it's important to be clear that there is a commercial service (API high speed access, customer support, SLAs) and not a content license. I've passed this on to the WMF comms team - no promises that we can get them to adjust the phrasing though. LWyatt (WMF) (talk) 12:15, 15 January 2026 (UTC)Reply

Ping Andy - The Associated Press article (from which the Independent article was syndicated) has now been updated to use the phrase "business deal", which is an improvement. Hopefully this will be propagated to anywhere that syndicated the piece. LWyatt (WMF) (talk) 14:56, 15 January 2026 (UTC)Reply

The Independent have changed their headline—to "Wikipedia commemorates 25th anniversary by inking AI licensing deals". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 15 January 2026 (UTC)Reply

hmm... I'm not sure if that's an improvement. Oh well, we tried. LWyatt (WMF) (talk) 16:09, 15 January 2026 (UTC)Reply

As for the second point - this is related to the same underlying issue of the first: that 'paying for the highspeed API' is not a copyright license, so the existing rights/obligations of CC By-SA already exist regardless of which manner anyone accesses the content. However, by using this high-speed-feed and our partners now having made a long term commitment to it (technically, financially) we are using that relationship to help these organisations to more consistently, visibly, accurately attribute the content they are obtaining from Wikimedia. How this manifests will of course be different for each external organisation and use-case. But we're certainly trying! LWyatt (WMF) (talk) 12:21, 15 January 2026 (UTC)Reply

I was asked this elsewhere and wasn't confident in my answer. Does the CC-BY-SA license require AI companies to publish the models trained on Wikipedia content under a compatible license? Or is it more that if they were to publish the models, they would have to do so under a compatible license? Or some third thing? GorillaWarfare (talk) GorillaWarfare (talk) 16:17, 16 January 2026 (UTC)Reply

Hi Molly, I've seen the question and have forwarded it to WMF-Legal for as precise an answer as possible. bear with me. LWyatt (WMF) (talk) 16:58, 16 January 2026 (UTC)Reply

See e.g. this statement from Creative Commons. The requirements of the CCPL (and all other licenses) only pertain to usage that requires permission under copyright. There is reason to believe that exceptions like fair use or the European TDM exception apply to usage like training generative models. And therefore, the BY and SA requirements of the CCPL have no bite.

On the other hand, how licenses of any kind can even be applied to such trained models is an interesting question itself. This is a series of fractal rabbit holes, and I tried to summarize it some months ago. -stk (talk) 19:29, 21 January 2026 (UTC)Reply

This assumes that the output of the models is original (albeit derived from training) and not just straightforward plagiarism.

I'm sure we have seen example of the letter. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:03, 21 January 2026 (UTC)Reply

Hey there, I'm an attorney on WMF's legal team. LWyatt flagged this thread for me. A short (if somewhat unsatisfying) answer is that courts are still resolving how copyright law applies to AI training and outputs. There's a number of US cases ongoing right now involving different training methods and legal theories, but none have yet produced a big precedential decision. As stk mentioned, the outcome(s) of these cases may have a big impact on reusers' obligations under the CC licenses, including potentially the ShareAlike requirement. As for the text/requirements of the ShareAlike term itself, CC has put out some (light, non-binding) guidance as the license drafter, in addition to what LWyatt and stk shared. However, courts are the only ones that can give an 'official' interpretation of the licenses. Jbuatti (WMF) (talk) 20:21, 22 January 2026 (UTC)Reply

See e.g. also Szkalej and Senftleben 2024 for the intricacies of this topic.

The practicality of SA is a whole different topic. I made a mockup a couple of years back how the byline at the bottom of OpenStreetMap would look like if all the contributors to the current bounding box were to be displayed there every time. Which also leads to followup questions like how a system could even determine whose inputs contributed to what percentage to a current output etc, and how this would benefit the idea of the Commons if one were to read through 10 pages of potential “contributors”.

It's different when RAG comes into play IMO, as outlined in my blog post I linked above. -stk (talk) 10:28, 24 January 2026 (UTC)Reply

Thanks to Andy for calling out that "licensing deals" misrepresentation (and to Liam/Enterprise for maintaining clarity in that regard).

For those not familiar with the underlying problem, I tried to explain it a bit in last month's Signpost (prompted by a Reuters headline that had already used this misrepresentation): "Wikimedia Foundation wants more AI companies to pay for API access" (the piece also discusses why despite the temptation that some news organizations might feel to frame Wikimedia Enterprise as a vindication of their own AI licensing/anti AI fair use approach, WMF is in a different situation, and why proposals that Wikimedia sites should join Cloudflare's AI bot blocking scheme are problematic).

Regards, HaeB (talk) 17:36, 15 January 2026 (UTC)Reply

Hi! Here from the English Wikipedia discussion – from which I really appreciate the "paying for the pipe rather than for the water" analogy. I'm happy to see the matter being clarified, and would be happy if we could proactively reach out to the relevant media, if possible, to reinforce that analogy and clarify that we aren't talking about a licensing deal.

Regarding the 25th anniversary timing, Wikimedia movement's can approach that special occasion, and the communication opportunities it allows us, from different angles. Media outlets have mostly focused on what we might call the "pro-AI angle" of the partnership: Wikimedia gets to sign deals, and grow closer, with large AI firms, which many people today see with increasing suspicion. But we could also emphasize the "pro-human angle": we alleviate the strain in resources that AI companies put on our API and server demands, keeping the main infrastructure human-focused by building this alternative pipeline. And we can then, through this framework, start addressing the next crucial issues like content attribution. The latter part was pointed out by LWyatt (WMF) on the English Wikipedia post, and I would be happy to see the Wikimedia Foundation's plans for such an endeavor.

This approach also clarifies that this is purely a "pipeline deal", instead of signing over licensing rights (as the content is freely licensed and the rights belong to Wikimedia contributors) or integrating commercial AI technology into Wikimedia projects. Chaotic Enby (talk) 14:34, 16 January 2026 (UTC)Reply

Thanks for your comments C.E.

Yes, we have tried to emphasise in our communications that this API service, and this specific announcement of new customers, is about long term relationships built on sustainable use of our infrastructure and considerate use of the content. This is an overlapping and nuanced discussion of bandwidth, copyright, attribution, revenue diversification, knowledge-integrity/misinformation, knowledge-dissemination and downstream-access.... but can be too easily summarised in the media as "selling the content".

We all know that AI services are built upon Wikipedia content already, so this service (and this announcement) at least allows us to take back some agency within that ecosystem - to re-emphasise the humanness of the content they're ingesting, and to ensure they invest in it for the long term.

For those who've come to this page for the first time based on the news derived from this week's customer announcements, I would encourage you to stick around and read some of the documentation - e.g. our operating principles, or the quarterly tech updates/roadmap. I also suggest reading the #4th annual financial report.

LWyatt (WMF) (talk) 18:12, 16 January 2026 (UTC)Reply

Soon we will able to breathe the word "realistic medieval world" and an AI will be able to comb all the Wikipedia articles and sources related to this topic and generate an entire reconstructed reality of the past and it wouldn't be possible if Wikipedia hadn't thoroughly maintained and built up the knowledge over 25 years, especially the link to (archived) sources so the AI creation tools can simulate an entire reality as realistically as possible while sticking to history and TRUE facts. ~2026-46627-2 (talk)

I was surprised to read "and Wikipedia apps for iOS and Android allow Wikipedia fans to access content right from their mobile devices." My understanding is that the goal for the apps (and I suppose the goal of the foundation) is to improve access for everyone. Presumably, part of the target with apps is to engage people who interact with the internet through apps rather than browsers. Suggesting such apps are only for "fans" undercuts these goals and presents the apps explicitly as non-universal. It would be more encouraging if press releases rhetorically promoted wider engagement, rather than making the oft-raised problem of not bringing in newer participants an inherent assumption of the framing. CMD (talk) 15:44, 16 January 2026 (UTC)Reply

I do agree with this, although I also see the vision of community-building in calling users "Wikipedia fans". Maybe the wording could highlight both, such as "Wikipedia fans and casual users alike", or another similar idea? Chaotic Enby (talk) 16:23, 16 January 2026 (UTC)Reply

The specicfic phrase you're quoting comes from within the press-release about the 25th birthday celebrations - the audience for which is journalists who will then [hopefully] write articles about the different things in the wikimedia universe that are of interest to them - and to contact us for more specific quotes/followup questions. I will nonetheless pass on C.E.'s suggestion for an adjusted phrasing to the WMF Comms team. If you/anyone would like to discuss the specific use-cases and technical design of the mobile apps, then I suggest you go to the relevant talkpage over on MediaWiki at mw:Wikimedia Apps - as that's an entirely different thing to the API that this talkpage is about. LWyatt (WMF) (talk) 18:04, 16 January 2026 (UTC)Reply

Thanks a lot! Especially since media can easily distort the intended meaning, it is good to have clear wording elements ourselves. Chaotic Enby (talk) 18:04, 16 January 2026 (UTC)Reply

Maybe the team could pre-empt journalists with a "deal" phrase for them to copy. "API deals"? CMD (talk) 00:06, 17 January 2026 (UTC)Reply

As someone who's given a few media interviews, I'm usually in contact with the Comms team, who works on these aspects. I presume that this could be helpful to include in their briefing docs, if @LWyatt (WMF) wants to pass that along too! Chaotic Enby (talk) 00:11, 17 January 2026 (UTC)Reply

We've published a use case article on the Enterprise blog today: Ecosia Enriches Search Results and AI Answers with Wikimedia Enterprise. We looked back on our collaboration efforts with Ecosia over the past year, and asked them for some more insights into how they were using the Wikimedia Enterprise API endpoints for their products. This use case is meant to give insights into how mission-aligned partners are using Wikimedia Enterprise APIs as a way to power their projects, hopefully inspiring other users of our endpoints to do the same. In future, we'd love to hear from more Wikimedia Enterprise users: how are you using our endpoints? Do you have any open-source repositories or code examples that we can share so that we can foster collaborative builds? What are the challenges that you're trying to overcome, and how might the further development of Wikimedia Enterprise API endpoints help?

If you have any questions or comments about this article or about our use cases in general, I'm happy to chat! --JWuyts-WMF (talk) 16:57, 16 February 2026 (UTC)Reply

Dear Wikimedians,

Since the very beginning of this project there has always been various “free access methods” for accessing the APIs even though its primary purpose is for the needs of large commercial organisations (and to raise revenue for the Wikimedia Foundation from that use). This has included free access via WikimediaCloudServices, database dumps on third-party platforms, and via free accounts on the official service itself. This is described at Wikimedia_Enterprise#Access.

There has also always been the additional free option for a specific/personal exception to be granted for what would otherwise be a paid level of speed/volume. Until today, this been described on the "access" page as:

Those who have a non-commercial and mission-relevant use-case, which cannot be fulfilled by existing free-access APIs/dumps etc, can request expanded access to the API service at either reduced cost or no cost depending on usage and application.

This remains true. But, as of today, that process is now being documented more thoroughly. Also today, the project operating Principles have been updated to explicitly reinforce this fact by adding the following:

Access for all. Wikimedia Enterprise offers, and will continue to offer, access at no cost (including for commercial use) at a defined volume. Any requests for exceptional access to a paid account at no cost will be reviewed according to published criteria.

Working in particular with colleagues at Wikimedia Deutschland - considering that we hope Wikidata will form an increasingly important use-case for high-volume access to Wikimedia’s APIs - we have now developed six criteria for making an exceptional access request to for free access to a paid account to Wikimedia Enterprise APIs. These are, in summary: Who, What, Need, Obligation, Mission alignment, and Value Alignment.

The documentation for criteria are copied here below for convenience, but live at Wikimedia Enterprise/Access and are transcluded on to the Wikimedia Enterprise main page:

Exceptional access criteria

1. Who (individual or organisation) is requesting exceptional access? Please list the contact person’s name, organisation (if applicable), email address, and Enterprise API account username. 2. What is the request for? Please specify what specific exception is being requested, and for what purpose. Please link to any documentation, existing service or project, research proposal, etc. that shows the use-case. Notes All users of Wikimedia Enterprise services must abide by the copyright licenses on Wikimedia content. They are inherent and cannot be waived. Please also note the API Usage guidelines (in particular regarding sub-licensing) and any Wikimedia Foundation policies which may apply to the proposed use-case – including the Terms of Use, the User-Agent Policy. 3. Need. Can the intended use-case be fulfilled via any of the existing free access methods? Please specify how the existing public services (e.g. public database dumps, APIs, or bots, etc.) are insufficient for your needs. Notes Exceptional free access to a paid account can only be granted when all standard options are exhausted - including the free account of the Enterprise services. Possible examples include: Persistent need for access above the Enterprise API requests/second, or datasets/month, free thresholds Creation of a new feature/dataset Formal customer-service or Service Level Agreement (SLA) requirements 4. Obligation. Would the intended use case require custom development to support or maintain? What is the duration of the requested exception? Please specify if the proposal can be fulfilled using the features of the existing APIs and datasets. If necessary features or datasets are not already available, please clarify with reference to the published documentation. Notes Providing exceptional access is effectively a form of in-kind support. The value includes any initial and ongoing development support, and infrastructure expense (in particular, data transfer costs). Contributions back to the Wikimedia movement (e.g., through content donations and data reports, tools, infrastructure, volunteer support and activities, and technical collaborations) could be understood as reciprocal in-kind contributions. In accordance with the Wikimedia Enterprise operating principles regarding non-exclusivity, any newly developed software feature or dataset must be made available to all. This might raise the financial cost of operating the service considerably, or decrease the strategic value of the proposed use case. 5. Mission alignment. Is the intended use case aligned with any of the needs identified in the Movement Strategy Recommendations? Please explain how the intended use will help the Wikimedia movement reach at least one of these goals. Notes There is no perfect definition of “mission alignment”. Nevertheless, the Movement Strategy recommendations (2020) represent the culmination of wide-ranging consultation across the Wikimedia community and stakeholders about our future. Its recommendations are broad in scope, stable, and independent of any one stakeholder’s needs. Special consideration would be given to organizations serving marginalized communities, underrepresented languages, or Wikimedia sister projects. The proposed use-case should not deliberately create or reinforce closed knowledge silos, proprietary forks of the content, or circumvent community norms or policies. 6. Values alignment. Do the requester’s professional practices or business model align with Wikimedia’s values? Please explain how the request (individual or organization) is in support of these values. Notes A human rights assessment is undertaken by the WMF for certain users of paid accounts for the Enterprise APIs (regardless of payment or exceptional access), in accordance with the Human Rights Policy and Commercial Sales and Contracts Policy. However, in order to receive free access to a paid account, the user should also be able to demonstrate a commitment to open knowledge, transparency, and/or public-benefit mission (such as education, cultural heritage, intergovernmental agency). Within a commercial organisation, specify if the lack of exceptional access to a paid account for the service that access would significantly jeopardize a public-benefit mission - essential for research, accessibility, public information or safety, for example. The business-model should at the very least not be in conflict with Wikimedia’s values – for example by being built upon harmful misinformation, disinformation, human rights violations, extractive data use, unethical generative AI, or undisclosed paid-editing practices on Wikimedia sites.

For anyone wishing to request "exceptional access", please contact <techpartnershipswikimedia.org> with a response to the six criteria described here.

Relatedly:

We are very pleased to announce that Wikimaps.space - a data-visualisation project of Wikipedia, affiliated to the University of Lausanne - is the first project to receive exceptional access at no cost through this process, due to their Wikimedia mission-aligned use case. This means that all 40 of the Wikipedia language editions they track will soon be processed via the Enterprise API.

We hope to eventually collaborate on publishing a case-study of their use-case on Enterprise project's blog.

Sincerely, LWyatt (WMF) (talk) 14:59, 23 February 2026 (UTC)Reply

@LWyatt (WMF): In Values alignement it says it cannot be used for "unethical generative AI" but doesn't define what that would be. Where is the line drawn by WME? Also, is that really just for exceptional access and regardless of where the line is drawn, if you pay, you may use it for unethical generative AI? ♥Ainali ^talk_{contributions} 07:11, 27 February 2026 (UTC)Reply

Hi @Ainali, this phrase is similar to many keywords used in these criteria in being subjective/qualitative rather than being objective/quantitative. Others include "harmful misinformation", "marginalized communities", "volunteer support", "extractive data use", "essential for research"... None of the criteria describe firm or automatic approval or rejection thresholds - in all cases it would be contextual.

The threshold for what one person would consider "unethical" is likely to be different for many people. But at least by listing the concept here - in a section with a list of other objectionable activities - it sets out the spirit of the process. Therefore if someone is asking for an exception and their use-case IS indeed GenAI, then it is incumbent upon them to proactively address the issue of ethics in their request. Not having addressed ethics or values (either in responding to these questions, or in some other documentation (e.g. university research approval paperwork) would be the red-flag.

In this specific case, the original addition of the phrase "unethical generative AI" was actually a suggestion from our WMDe colleagues, when we were drafting these criteria together. I'll ping them about this question in case they wish to add something as a comment here.

As for the second part of the question:

This "exceptional access" process is based on requests for specific use-cases, so it is that specific thing that is being reviewed for whether it meets these criteria (and when their use-case is no longer needed, their exceptional access would be withdrawn too). Granting an "exceptional access" request is - in effect - a grant with a real in-kind value - a subsidy of a third-party activity at WMF expense. so it's incumbent on us to show that the activity is actively supportive of the mission/values. On the other hand, when it is a customer in the commercial sense, we're not "vetting" their individual products/activities that they might use the dataset - they are purchasing accessing to a feed of data and there is no subsidy by the WMF/Enterprise, no 'endorsement' of individual use-cases. This is where the Human Rights and Commercial-Sales policies come in to effect (linked in the notes of criteria 6). They provide for a broader review of the customer as a whole and also for a WMF Board of Trustees review and, if necessary, the right to refuse a customer entirely. LWyatt (WMF) (talk) 11:29, 27 February 2026 (UTC)Reply

This is so beautiful! Do the developers have wiki accounts and a project page here as well? –SJ talk  22:25, 28 February 2026 (UTC)Reply

Hi SJ, I’ll inform them about your questions. LWyatt (WMF) (talk) 22:30, 28 February 2026 (UTC)Reply

Want to bring up a discussion I had with @LWyatt (WMF) offwiki regarding whether volunteers are equipped to use the enterprise API, in the context of the recent planned rate limits on normal APIs. Primarily, I wanted the answer to the following questions:

• Is the Enterprise API open-source, can contributors make changes to the API if they feel that their needs are not met? To my understanding there hasn't been any significant contributions by volunteers to the APIs and it is not obvious to me what kind of contributions are even welcomed. (Or whether this a is "source available" situation)
• Is there any intention of providing more than 5000 requests/month to volunteers who could use the Enterprise API? For context, as it currently stands, the free 5000 req/month limit is very low compared to what any volunteer who might want to run a bot might use. For context, English Wikipedia, being one of the more conservative wikis in terms of edit rate has a maximum cap at 20 req/minute (appeal-able by community consensus), if we try to compare the enterprise limit, we arrive at 6 requests per hour. Both are not comparable and would lead to massive slowdowns if WMF wants us to potentially use the Enterprise APIs for large-scale volunteer work? (I understand that there is a process for granting higher API limits on a case by case basis but it would seem like for most bots or similar, a rate higher than 5k lookups per month would be desireable)

Sohom (talk) 22:42, 2 March 2026 (UTC)Reply

Hi @Sohom:

For your first question - The links to the GitHub, GitLab, and can be found on our FAQ here. It is freely-licensed code. Quarterly technical updates are published here. (there's also a blog with tech updates [e.g. 2025 annual review).

Notwithstanding that the primary purpose/usecase of this API is commercial customers - it remains open for anyone to use at no cost (at a lower rate, without SLAs), and consequently - on our Phabricator bug tracker there is a dedicated column for community requests. Unsolicited community-contribution of code would be hard to integrate because the workflow and roadmap of the relevant engineering team is not set up for that. But moreover, few (none?) volunteers would be interested in writing code for free, for large commercial organisations' usecases. Nevertheless, if there's something you would like to propose - through that phabricator board - that upon discussion and review is triaged as important, and you would like to help work on it... then I'm sure you could discuss that with the team's product delivery manager User:JArguello-WMF.

For the second question - The examples you give are all with regards to editing and contributing content on the wikis. As noted in the FAQ, the API "has no technical or editorial control over the content in Wikimedia projects." - it is a read not a write system. It is designed for large volume and/or high speed downloading of Wikimedia content for reuse in third-party services (notably Search, or AI) but has no method of editing the pages themselves.

The 5000-requests per month limit for the general free access Enterprise "on demand API" is for anyone who wishes to update individual article of particular importance to them since the previous whole-wiki copy (from the "Snapshot API") which is updated, for free, every two weeks. It generates what is effectively a "diff" from the previous database copy you have vs. the current live version.

I hope that helps clarify. LWyatt (WMF) (talk) 00:57, 3 March 2026 (UTC)Reply

@LWyatt (WMF), @JArguello-WMF: As a aside for on our Phabricator bug tracker there is a dedicated column for community requests. - The fact that there are legitimate issues from 2022/2023 that are still open (like T318371 and T331765) makes me somewhat skeptical that there is any work at all that is occuring on community-relevant issues. (I get that you are trying to optimize for non-community usecases, but >3 years to work on "guys the data you are providing is corrupted" and "would it be possible to include two more namespaces" seems like a hard sell for "we work on community requests".)

Coming to the question at hand, based on your description of the Enterprise API, I'm entirely failing to grasp any usecase for the community to use this API shape and I don't understand how/why it is being considered an alternative to our API limits. The community typically only has editing or contributing content as a use-case and while those kinds of use-cases typically need a read before a write (you can theoretically have write-only job, but that doesn't get very far). However, being severely limited in the number of requests does not help or having to access two week old content completely defeats this usecase.

To be very honest, I can understand that the API is read-only for obvious reasons (and I don't expect y'all to provide a editing API), but I feel like the API-shape is still severely limiting even in a reading-only "hobby" usecases. If I wanted to (say) to run some analytics on page content, or even potentially to make a small category of pages searchable through a locally hosted AI/LLM, surface previews of Wikipedia pages linked to from my blog (that is regularly featured at HN) or to dynamically display commons images on a platform that might see high-traffic I would be stuck between the pot (API rate limits) and the kettle (non-usable/bad Enterprise API shape) even if I was okay with paying Enterprise some money. Sohom (talk) 18:47, 4 March 2026 (UTC)Reply

The last example is concretely occuring (to my understanding) at [1]. Sohom (talk) 18:50, 4 March 2026 (UTC)Reply