📖 Developer Satisfaction 2025 Report

🔌 Wikimedia APIs

tl;dr

Awareness - Respondents are most aware of Action API, Wikidata SPARQL Query Service, and Wikimedia REST API.
Use - Respondents use Action API the most.
Tenure - 55% have been using Wikimedia APIs for >5 years.
Builds - 53% use Wikimedia API(s) to build bots or gadgets.
Use cases - More than half use Wikimedia API(s) to enhance on-wiki user experiences and/or automate tasks on a Wikimedia project.

# 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 138 who responded, the majority (76%) 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 109 who responded,

55% reported having used Wikimedia APIs for more than 5 years
21% reported 3-5 years
12% reported 1-3 years
12% 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 and Extension APIs were used the most.

API	Respondents aware of this API		Respondents who have used or contributed to this API
API	N	%	N	%
Action API	101	97%	95	91%
Wikidata SPARQL Query Service	95	91%	64	62%
Wikimedia REST API	93	89%	52	50%
Wikidata REST API	81	78%	41	39%
Wiki Commons SPARQL Query Service	79	76%	22	21%
Wikimedia Enterprise APIs	77	74%	5	5%
Wikimedia Analytics API	77	74%	43	41%
Other* Wikimedia APIs	63	61%	22	21%
Extension APIs	60	58%	45	43%

API	Out of the respondents who said they were aware of this API, % who have used or contributed to this API
Action API	94%
Wikidata SPARQL Query Service	67%
Wikimedia REST API	56%
Wikidata REST API	51%
Wiki Commons SPARQL Query Service	28%
Wikimedia Enterprise APIs	6%
Wikimedia Analytics API	56%
Other* Wikimedia APIs	35%
Extension APIs	75%

* The most commonly mentioned "other" Wikimedia APIs were Liftwing and Wikifunctions

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 (62% of respondents reported using very or somewhat frequently)
Wikidata REST API (50% of respondents reported using very or somewhat frequently)
Extension APIs (44% of respondents reported using very or somewhat frequently)
Wikidata SPARQL Query Service (45% of respondents reported using very or somewhat frequently)

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
63% reported never or very infrequently using APIs to build data visualizations or dashboards

top

# API use cases

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

Respondents’ most common use cases:

54% reported using Wikimedia APIs to enhance on-wiki user experiences
52% reported using Wikimedia APIs to automate tasks on a Wikimedia project

Respondents’ least common use cases:

90% reported never or very infrequently using Wikimedia APIs to train an ML/LLM/AI algorithm
70% reported never or very infrequently using Wikimedia APIs to automate tasks on a third party MediaWiki extension
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:

83% agreed that “the endpoints return data in a format that is usable for me”
69% agreed that “announced change and deprecation cycles are long enough”
69% agreed that “endpoint availability and behavior is consistent, and matches my expectations”
60% agreed that “the documentation is accurate”

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:.”

Some commons themes emerged from the answers to these questions.

Documentation

A quarter of all responses (11 of 44) included calls for improved documentation. Of the 11 calls for documentation, over half (6 of 11) of them mentioned a desire for standardized, modern, and interactive documentation powered by OpenAPI (aka: Swagger) specs directly. Discoverability of documentation was another common theme, where respondents mentioned too many available documentation portals, some of which are incomplete.

“REST API sandbox & generated docs”
“Swagger API docs”
“I'm reluctant [to use] unless the Action API is strongly versioned with OpenAPI specs to boot.”
“Ideally there would be some machine-readable description of the output format, from which I can generate interface definitions in my favorite programming language.”
“I am heartened to see a move toward more true REST APIs and adopting standard, out of the box solutions such as Swagger.”
“Better documentation for each endpoint and easy access to it.”

Consistency

Nearly half (21 of 44) of all responses alluded to issues related to a lack of consistency across endpoints and API experiences. Themes within the responses included: too many API options with not enough distinction between when or why to use one set of endpoints over another, a lack of consistency around common features like error responses and authentication patterns, and the Wikimedia API offerings feeling too different from other APIs.

“One API to rule them all, One API to find them... (you know the rest).”
“https://xkcd.com/927/”
“The Action API is an abomination. Its usage patterns are unlike any API I've ever used.“
“We need to stop doing things only we do and start doing more things that everyone else already does.”
“We have too many API portals”
“I don't understand why the action api is distinct from the REST api. Having this split just makes it more complicated to find what you need.”

Reliability & Support

One quarter (11 of 44) of all responses called out the need for more reliable, well supported API capabilities. Common themes included support for versioning and deprecation, as well as improving communication around outages and upcoming changes.

“...every change, however small it is, is potentially breaking, so my consumers can break at any time”
“Changes to the MediaWiki REST API framework are not communicated ahead of time and feedback not gathered.”
“I don't think we are able to effectively deprecate API endpoints. We are still using 'v1' of the action API for pete's sake! I'd like to see consistent mechanisms that allow us to effectively deprecate and remove APIs.”
“Better reliability and capacity (higher rate limits).”
“Monitoring dashboard to check if an API is down.”

Functional Gaps

12 of 44 responses called out specific functional gaps: 4 responses included themes of filtering and supporting more targeted requests; 4 responses included requests for additional project or feature coverage that does not currently exist in the API; and 4 responses called out specific infrastructure or endpoint behavior no longer meeting user needs.

“Filtering lint errors by error type or category.”
“Wikidata SPARQL timeouts occur to often.”
“Data as a product. HTTP request APIs are not good for timely or bulk historical data usage, for which there are many researcher, staff developer, and tool builder use cases.”