📖 Developer Satisfaction 2026 Report

🔌 Wikimedia APIs

tl;dr

Awareness - Like last year, respondents are most aware of Action API, Wikidata SPARQL Query Service, and Wikimedia REST API.
Use - Like last year, respondents say they use Action API the most.
Tenure - Like last year, about half of respondents have been using Wikimedia APIs for >5 years.
Builds Like last year, more than half of respondents use Wikimedia API(s) to build bots or gadgets.
Use cases - Like last year, more than half of respondents use Wikimedia API(s) to enhance on-wiki user experience; fewer use these APIs to automate tasks on a Wikimedia project (42%, down from 52%)
Satisfaction - 89% of respondents agreed that the API endpoints return data in a usable format.
Policy awareness - The majority of respondents are aware of Wikimedia Foundation user-agent policy; although not all are compliant, and some still have questions about implementation.

# API use

“As part of your role as a member of the Wikimedia developer community, have you ever used or created Wikimedia APIs?”

Of the 115 who opted in to this section and responded to this question, the majority (74%) said they have used or created Wikimedia APIs in the past year.

top

# API years of use

“About how long have you worked with Wikimedia APIs?”

Of the 84 who responded,

50% reported having used Wikimedia APIs for more than 5 years
23% reported 3-5 years
17% reported 1-3 years
11% reported less than 1 year

top

# Specific API awareness and use

“Which of the following Wikimedia APIs are you aware of / have you used or contributed to?”

Of the 104 who responded, the majority were aware of Action API, Wikidata SPARQL Query Service, and Wikimedia REST API. Of respondents who were aware of them, Action API was used the most.

* The "other" Wikimedia APIs mentioned were varied, and included Liftwing, Wikifunctions, and Pagepile.

top

# Specific API use frequency

“How often have you used or contributed to these Wikimedia APIs within the past year?”

The APIs with the most frequency of use reported were:

Action API (59% of respondents reported using very or somewhat frequently)
Wikidata SPARQL Query Service (54% of respondents reported using very or somewhat frequently, up from 45% last year)
Wiki Commons SPARQL Query Service (46% of respondents reported using very or somewhat frequently, up from 25% last year)

top

# API use for building

“How often have you used Wikimedia APIs to build the following?”

Respondents’ most frequent builds using APIs:

53% reported using APIs to build bots or gadgets very or somewhat frequently
40% reported using APIs to build external applications very or somewhat frequently

Respondents’ least frequent builds using APIs:

82% reported never or very infrequently using APIs to build mobile applications
75% reported never or very infrequently using APIs to build Internal Wikimedia features and services

top

# API use cases

“How often have you used Wikimedia APIs to enable the following use cases?”

Respondents’ most common use cases:

52% reported using Wikimedia APIs to enhance on-wiki user experiences
42% reported using Wikimedia APIs to automate tasks on a Wikimedia project (down from 52% last year)

Respondents’ least common use cases:

86% reported never or very infrequently using Wikimedia APIs to train an ML/LLM/AI algorithm
72% reported never or very infrequently using Wikimedia APIs to automate tasks on a third party MediaWiki installation
66% reported never or very infrequently using Wikimedia APIs to analyze traffic or usage behaviors

top

# API satisfaction

“Regarding Wikimedia APIs, how much do you agree with the following statements?”

Statements most agreed with:

89% agreed that “the endpoints return data in a format that is usable for me”
66% agreed that “endpoint availability and behavior is consistent, and matches my expectations”
65% agreed that “URL routing and response patterns are consistent and intuitive”
64% agreed that “announced change and deprecation cycles are long enough”

top

# API useragent policy

“Are you aware of the Wikimedia Foundation User-Agent Policy and how to be compliant??”

This year, we asked respondents if they are aware of the Wikimedia Foundation User-Agent policy. Of the 89 respondents who answered this question,

More than two thirds (70%) said "Yes, I am aware and provide a compliant user-agent on all of my API requests"
16% said "No, I am unaware of the policy"
15% said they are aware of the policy, but they either "haven't updated my requests to be compliant yet" or "don't understand what it means to be compliant"

top

# API wishlist and other feedback

“Which API feature(s) would you most like to see, to better support your Wikimedia developer experience?”
“Please share any other feedback you may have about Wikimedia APIs:.”

Core Coverage & Usability

The majority of responses (34 of 46) touched on core API coverage and usability. Of those, 9 of 34 were feature requests for missing capabilities related to core workflows. The most common asks were continued REST API support, feature parity between API and UI features, standardization of common concepts like pagination, and library or SDK support for popular languages. The Action API also drew significant criticism, most commonly pointing to gaps in response format documentation. Five responses were positive, specifically noting the addition of OpenAPI Specification documentation and the Enterprise APIs’ modern conventions as encouraging signs of continued API improvements.

“A newer version of the core article REST API with refined output and methods”

“The action API generally has good documentation on expected parameters, but there is zero documentation on the result format – the only two possibilities to find it out are trial-and-error (which may lead to wrong assumptions) and ‘use the source’ (which only works if you understand the PHP code and know where to find it).”

Specialized APIs: Wikidata & Commons

Roughly a third of responses (15 of 46) raised specialized API needs for Wikidata and Commons. Wikidata was mentioned in 10 of 46 responses, with common feature themes including requests to increase REST API coverage for things like query and edit endpoints, Q-ID lookup, lexeme coverage, event streams, and property-level batch access. Commons appeared in 7 of 46 responses, reflecting a general sentiment of underinvestment in this space. The most common concerns included unstable file upload APIs and limited image API coverage. Specific feature requests will be shared with owning teams.

“Hard to use the WCQS API … poor uptake, lack of clarity on whether it would remain supported — so why develop tooling for it?.”

Consistency & Fragmentation

Over a quarter of responses (12 of 46) touched on fragmentation or consistency concerns. Eight of those were explicitly negative, expressing frustration with the proliferation of API surfaces (Action API, REST API, api.wikimedia.org, SPARQL endpoints, and more) without clear guidance on how they relate or which to use. A recurring concern was also follow-through, given a history of some false starts, like the API Portal. Developers are wary of new experiences added to the pile that might be abandoned mid-migration, which results in further fragmentation and consistency challenges across API entry points.

“The whole platform needs an overhaul. The ‘APIs’ that are most useful for me are the abstractions like Wikibase Integrator. Too much in the core APIs is still tied to the underlying PHP-based infrastructure across the platforms. While this is great from a stability/predictability standpoint, they are too hard to use for most tasks.”

“No clear and up-to-date communication on differences between APIs. Especially when searching for Wikimedia APIs, https://api.wikimedia.org/wiki/API_catalog is also found, however it is not clearly visible that this is only one API of many and not THE Wikimedia API. This tripped me up when I first started investigating.”

Documentation & Discoverability

Documentation was also raised in over a quarter of responses (12 of 46). The two most common pain points were scattered documentation across multiple wiki pages and portals, as well the absence of response format documentation in the Action API. The lack of a centralized location for API documentation also corresponds to API discovery, where respondents expressed frustration and confusion about what APIs are available. More positive feedback included the use of examples in MediaWiki API docs, the newly released REST Sandbox, and OpenAPI spec coverage for our REST APIs.

“I think just clarity in documentation about the right APIs to use and discoverability of which APIs exist.”

“It’s difficult to discover which APIs are currently available. They’re spread across many categories whose meanings aren’t obvious at a glance, and the documentation is scattered across several wiki pages. A centralized API hub would make it much easier for people to find and understand what’s available.”