Hi all,
Summary: The API Portal wiki[1] is shutting down. API keys created on the
API Portal will continue to work (rate limits apply). api.wikimedia.org
endpoints will be deprecated gradually starting in July 2026. Documentation
on the API Portal is moving to mediawiki.org[2].
== Context ==
Started in 2020, the API Portal is an experimental wiki available at
api.wikimedia.org. It was designed by the Wikimedia Foundation as a home
for Wikimedia API docs and related functionality. The Wikimedia Foundation
has decided to shut down the API Portal as part of a new strategy for
Wikimedia APIs[3] and to focus on new ways to make API docs easy to find,
use, and create.
== Changes ==
Endpoints:
api.wikimedia.org endpoints will continue to work as currently documented
until at least June 2026. Starting in the second half of 2026, these
endpoints will be migrated to new routes, and the old routes will be
deprecated gradually. Deprecation information will be communicated through
the mediawiki-api-announce mailing list[4], Wikimedia API changelog[5], and
on the project talk page[6].
Rate limits:
Starting in late March or early April 2026, api.wikimedia.org endpoints
will have the same rate limits[7] as other Wikimedia APIs. The new rate
limits are higher than the current rate limits[8], so this change should
not create any issues. The Lift Wing API will continue to have the same
custom rate limits[9] with only minor clarifications.
API keys:
We expect API keys created through the API Portal to continue to work
normally within the API rate limits[7]. You can manage your API keys
through Meta-Wiki[10]. If you encounter any issues, please reach out using
the contact information below.
Documentation:
Documentation from the API Portal is currently being consolidated and moved
to other technical documentation wikis. Starting in June 2026, the API
Portal will be inaccessible. To learn about Wikimedia APIs and find links
to docs, visit the new landing page (work in progress) on mediawiki.org[2].
== Contact ==
If you have any questions, want to share your feedback, or have any issues
with functionality related to the API Portal:
- Post to the project talk page[6]
- Email techdocs(a)wikimedia.org
== Learn more ==
For a timeline, background behind the decision, and the latest project
information, see the project page[11].
Best,
- Alex Paskulin on behalf of the Wikimedia Tech Docs Team and MediaWiki
Interfaces Team
[1]: https://api.wikimedia.org/wiki/Main_Page
[2]: https://www.mediawiki.org/wiki/Wikimedia_APIs
[3]:
https://techblog.wikimedia.org/2025/06/12/apis-as-a-product-investing-in-th…
[4]:
https://lists.wikimedia.org/postorius/lists/mediawiki-api-announce.lists.wi…
[5]: https://www.mediawiki.org/wiki/Wikimedia_APIs/Changelog
[6]: https://wikitech.wikimedia.org/wiki/Talk:API_Portal/Deprecation
[7]: https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits
[8]:
https://wikitech.wikimedia.org/wiki/API_Portal/Deprecation#API_Portal_histo…
[9]: https://api.wikimedia.org/wiki/Lift_Wing_API/Rate_limits
[10]: https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/list
[11]: https://wikitech.wikimedia.org/wiki/API_Portal/Deprecation
--
Alexandra Paskulin
Technical Writer
Wikimedia Foundation
Hi all
As previously announced
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>,
we have started rolling out new global API rate limits across our APIs to
help ensure fair and sustainable access
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Content_Reuse>
to Wikimedia resources.
We have just enabled the first set of limits, which apply to anonymous
requests from bots and unauthenticated requests from web browsers. See the
documentation on mediawiki.org
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits> for more
information. This has now been updated with actual limits for anonymous
requests and authenticated bot requests that do not come from WMCS. We are
still finalizing the initial limits for User-Agent only (e.g.
InstantCommons) and authenticated browser requests.
As a next step, rate limits for logged in users will follow in early April
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Responsible_Reuse…>.
The concrete limits will be communicated beforehand. Access for clients
running in WMCS and accounts that have a bot flag will not be affected by
this change. However, all developers are advised to familiarize themselves
with the new limits and follow the best practices outlined in the
documentation.
If you see any unexpected issues that might be the result of the limits
rolled out this week, we are actively monitoring relevant mailing lists,
Talk pages and bot-traffic(a)wikimedia.org.
Best
Jonathan
--
*Jonathan Tweed* (he/him)
Senior Product Manager, Core Platform
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello, technical contributors!
The MediaWiki Interfaces team is deprecating XSLT stylesheets within the
Action API.
Support for the format=xml&*xlst={stylesheet}* will be removed from
Wikimedia projects by the end of November, 2025. In addition, it will soon
be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44,
and v1.45. Support for XSLT stylesheets will be fully removed from
MediaWiki v1.46 (expected to release between April and May 2026).
*=== Why are we deprecating and removing this capability? ===*
Support for XSLT is generally being removed from browsers, due to a high
rate of security risks and declining usage. Chrome is officially starting
the XSLT deprecation cycle
<https://developer.chrome.com/docs/web-platform/deprecating-xslt>in
November 2025, with full removal expected by November 2026. Other browsers
are expected to follow. To ensure that we are not including a feature that
will no longer be supported by browsers, we decided to end support, as
well.
*=== What is the impact? === *
There is currently very limited adoption of this feature across Wikimedia
projects, with usage limited to a handful of gadgets that currently rely on
this capability. We are engaging with some of the key gadget owners
directly, so they are aware of the change and can adjust or remove lesser
used features accordingly.
We also recognize that some third parties may rely on XSLT stylesheets. In
this case, we encourage consumers to find alternative solutions as soon as
possible, given the end of XSLT support goes beyond the scope of MediaWiki.
I encourage tool developers, gadget authors, and third party users to
engage directly if you have questions, concerns, or if this change may
block your ability to upgrade to future versions in a timely manner.
Thanks,
Halley
*Halley Coplin* (she/her)
Sr. Product Manager, MediaWiki Interfaces
Wikimedia Foundation <https://wikimediafoundation.org/>
Howdy API artists, bot builders, and tool tinkerers!
We are continuing to reroute all web API traffic through a common API
Gateway. This week, Action API traffic began flowing through the common
gateway. Requests from Group 0 wikis are now being routed through
the common gateway, and we expect to follow the following deployment
schedule for the remaining Wikimedia projects:
- 100% Group 0 today (Oct 30)
- 50% Group 1 on Monday, Nov 3
- 100% Group 1 on Wednesday, Nov 5
- All remaining wikis ramp up week of Nov 10
This is purely introducing another layer of infrastructure, and we expect
the change to be non-breaking and non-disruptive. We are also keeping a
close eye out for any anomalies as we dial up proportional traffic. If any
issues are observed in your own bots, features, or tools, please file a
phabricator ticket to the Service Ops team board
<https://phabricator.wikimedia.org/tag/serviceops/>.
Why is this change happening?
As mentioned in the API as a Product Tech Blog
<https://techblog.wikimedia.org/2025/06/12/apis-as-a-product-investing-in-th…>
published
earlier this year and as part of the WE5 objective
<https://meta.wikimedia.org/wiki/Talk:Wikimedia_Foundation_Annual_Plan/2025-…>
(KR5.2),
we are working to consolidate and centralize our API infrastructure.
Centralizing API routing will make observability across APIs easier,
allowing us to make better data-driven decisions. Having a single,
centralized API gateway also simplifies API management, enabling us to
continue streamlining and standardizing our API offerings.
What’s next?
We will continue rerouting non-MediaWiki endpoints through the common
gateway in the coming months. Keep an eye out for more announcements here
and on Tech News <https://meta.wikimedia.org/wiki/Tech/News>!
Feel free to respond here, find us on phabricator, or add to a on-wiki
discussion thread if you have any questions, comments, or concerns!
Thanks,
Halley
*Halley Coplin* (she/her)
Sr. Product Manager, MediaWiki Interfaces
Wikimedia Foundation <https://wikimediafoundation.org/>
Hello Wikimedia REST API users!
As part of the RESTBase Sunsetting project
<https://phabricator.wikimedia.org/T262315>, we are rerouting the lint
endpoints in the Wikimedia REST API
<https://www.mediawiki.org/wiki/Wikimedia_REST_API> through MediaWiki. Both
page and transform lint endpoints are affected. This change is expected to
be seamless and non-breaking. However, because this work involves a service
change, we would like your help to ensure that no tools, bots, or other
integrations relying on these endpoints are negatively impacted.
*==== Impacted endpoints ====*
Lint endpoints offered by the Wikimedia REST API
<https://en.wikipedia.org/api/rest_v1/> (under the /api/rest_v1/ path) are
being rerouted. No other endpoints are affected. The specific endpoints are
limited to:
GET /page/lint/{title}/
GET /page/lint/{title}/{revision}
POST /transform/wikitext/to/lint
POST /transform/wikitext/to/lint/{title}
POST /transform/wikitext/to/lint/{title}/{revision}
*==== Timeline & next steps ==== *
The rerouted endpoints are currently live on test.wikipedia.org -- please
feel free to test and verify functionality there at your earliest
convenience.
Assuming no issues are observed or reported, we plan to utilize the
following deployment schedule:
- *Tuesday, Oct 28*: Rerouting is live on test and test2 wikis.
- *Monday, Nov 3*: Enable rerouting on Group 0 wikis.
- *Tuesday, Nov 4*: Enable rerouting on Group 1 wikis.
- *Thursday, Nov 6*: Enable rerouting on all remaining wikis.
*==== How to report issues ====*
Please see T384216 <https://phabricator.wikimedia.org/T384216> for more
information, or to report any observed issues or changes in behavior
related to this rerouting. You may also reply directly to this email, or
file a new ticket to the MediaWiki Interfaces team board
<https://phabricator.wikimedia.org/project/view/6931/>.
Thanks,
Halley
*Halley Coplin* (she/her)
Sr. Product Manager, MediaWiki Interfaces
Wikimedia Foundation <https://wikimediafoundation.org/>
Greetings, REST API consumers!
We recently marked duplicate transform endpoints as deprecated in the
MediaWiki REST API. The deprecated endpoints reflect a trailing slash at
the end of the path, and are duplicative of comparable endpoints without
the trailing slash. Developers who are calling these endpoints are advised
to remove the trailing slash from the path their requests. *We plan to
remove the trailing slash endpoints by the end of January 2026*.
*== What should I call instead? ==*
Identical endpoints already exist; simply remove the trailing slash from
your requests and the calls will go through. Users can review documentation
and execute test calls for both versions of the transform endpoints using
the new REST Sandbox <https://www.mediawiki.org/wiki/Special:RestSandbox>
(Special:RestSandbox), as seen below:
[image: image.png]
*== Why are we deprecating and removing these endpoints? ==*
These endpoints contain a trailing slash in the path, which is confusing
for consumers and goes against REST routing paradigms. The trailing slash
was added erroneously within the MediaWiki Core APIs and resulted in
duplicate routes when combined with endpoint migration for the RESTBase
Sunsetting project. Few users have adopted the trailing slash version,
which is motivating us to move quickly on its removal, before more tools,
bots, and developers are impacted.
*== Will this result in a major version change for the MediaWiki REST API?
==*
No. Although this is technically a breaking change, we plan to remove the
endpoints without incrementing the major version across the board. In this
case, we decided to proceed with removal without a version increment due to
the limited adoption of these specific endpoints, and to minimize
disruption across our developer community as a major version change may
have more cascading impacts.
*== Where can I get more information about the deprecation process? ==*
For more information about our approach to deprecation overall, see the new API
Deprecation <https://www.mediawiki.org/wiki/API/Deprecation> page for more
information about deprecation processes.
If you have any questions, comments, or concerns, please feel free to raise
them here, or join the discussion on the new API Deprecation talk page
<https://www.mediawiki.org/w/index.php?title=Talk:API/Deprecation>.
Thanks,
Halley
*Halley Coplin* (she/her)
Sr. Product Manager, MediaWiki Interfaces
Wikimedia Foundation <https://wikimediafoundation.org/>
The OAuth identity endpoint (the Special:OAuth/identify special page for
OAuth 1, the oauth2/resource/profile REST API endpoint for OAuth 2) used to
return an incorrectly formatted JSON web token, where value of the 'sub' field
(the user's CentralAuth central user ID) was an integer, rather than a
string as required by the JWT spec.
Due to the latest release of the pyJWT library getting more strict about
format validation, this started causing errors in various tools recently.
As of this week, this behavior has been fixed for Wikimedia sites, and it
has been fixed in all maintained versions (MediaWiki 1.39 and upwards) of
the OAuth MediaWiki extension which provides this API. Because the old
behavior was a spec violation and caused errors, and it's unlikely the
correct behavior would break clients, we are making this fix as a breaking
change rather than following the usual API deprecation policies.
For more details and discussion see
https://phabricator.wikimedia.org/T382139
Hello,
In the list=tag API query module, the tag source type named "extension" is
being renamed to "software" [1]. As of MediaWiki 1.42, "extension" still
appears alongside "software" in the tag source lists but is deprecated [2].
In future versions of MediaWiki, the "extension" entries will no longer
appear.
The use of "extension" is misleading since it does not exclusively refer to
tags defined by MediaWiki extensions (via the onListDefinedTags hook), but
also those defined in MediaWiki core (via
ChangeTagsStore::DEFINED_SOFTWARE_TAGS). The distinction isn't really
useful to clients anyway.
(this message was cross-posted from wikitech-l)
[1] https://phabricator.wikimedia.org/T247552
[2]
https://en.wikipedia.org/w/api.php?action=query&list=tags&tgprop=source&tgl…
---------- Forwarded message ---------
From: Adam Baso <abaso(a)wikimedia.org>
Date: Wed, Mar 22, 2023 at 4:45 AM
Subject: Service Decommission Notice: Mobile Content Service - July 2023
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
TL;DR: The legacy Mobile Content Service is going away in July 2023. Please
switch to Parsoid or another API before then to ensure service continuity.
Hello World,
I'm writing about a service decommission we hope to complete mid-July 2023.
The service to be decommissioned is the legacy Mobile Content Service
("MCS"), which is maintained by the Wikimedia Foundation's Content
Transform Team. We will be marking this service as deprecated soon.
We hope that with this notice, people will have ample time to update their
systems for use of other endpoints such as Parsoid [1] (n.b., MCS uses
Parsoid HTML).
The MCS endpoints are the ones with the relative URL path pattern
/page/mobile-sections* on the Wikipedias. For examples of the URLs see the
"Mobile" section on the online Swagger (OpenAPI) specification
documentation with matching URLs here:
https://en.wikipedia.org/api/rest_v1/#/Mobile
== History ==
The Mobile Content Service ("MCS") is the historical aggregate service that
originally provided support for the article reading experience on the
Wikipedia for Android native app, as well as some other experiences. We
have noticed that there are other users of the service. We are not able to
determine all of the users, as it's hard to tell with confidence from the
web logs.
The Wikimedia Foundation had already transitioned the Wikipedia for
Android and iOS apps to the newer Page Content Service ("PCS") several
years ago. PCS has some similarities with MCS in terms of its mobility
focus, but it also has different request-response signatures in practice.
PCS, as with MCS, is intended to primarily satisfy Wikimedia
Foundation-maintained user experiences only, and so this is classified with
the "unstable" moniker.
== Looking ahead ==
Generally, as noted in the lead, we recommend that folks who use MCS (or
PCS, for that matter) switch over to Parsoid for accessing Wikipedia
article content programmatically for the most predictable service.
The HTML produced by Parsoid has a versioned specification [2] and because
Parsoid is accessed regularly by a number of components across the globe
tends to have fairly well cached responses. However, please note that
Parsoid may be subject to stricter rate limits that can apply under certain
traffic patterns.
At this point, I do also want to note that in order to keep up with
contemporary HTML standards, particularly those favoring accessibility and
machine readability enhancements, Parsoid HTML will undergo change as we
further converge parsing stacks [3]. Generally, you should expect iteration
on the Parsoid HTML spec, and of course as you may have come to appreciate
that the shape of HTML in practice can vary nontrivially wiki-by-wiki as
practices across wikis vary.
You may also want to consider Wikimedia Enterprise API options, which range
from no cost to higher volume access paid options.
https://meta.wikimedia.org/wiki/Wikimedia_Enterprise#Access
== Forking okay, but not recommended ==
Because MCS acts as a service aggregate and makes multiple backend API
calls, caveats can apply for those subresources - possibility of API
changes, deprecation, and the like. We do not recommend a plain fork of MCS
code because of the subresource fetch behavior. This said, of course you
are welcome to fork in a way compatible with MCS's license.
== Help spread the word ==
Although we are aware of the top two remaining consumers of MCS, we also
are not sure who else is accessing MCS and anticipate that some downstream
tech may break when MCS is turned off. As we are cross-posting this
message, we hope most people who have come to rely upon MCS will see this
message. Please feel free to forward this message to contacts if you know
they are using MCS.
== Help ==
Although we intend to decommission MCS in July 2023, we would like to share
resources if you need some help. We plan to hold office hours in case you
would like to meet with us to discuss this or other Content Transform Team
matters. We will host these events on Google Meet. We will provide notice
of these office hours on the wikitech-l mailing list in the coming weeks
and months.
Additionally, if you would like to discuss your MCS transition plans,
please visit the Content Transform Team talk page:
https://www.mediawiki.org/wiki/Talk:Content_Transform_Team
Finally, some Content Transform Team members will also be at the Wikimedia
Hackathon [4] if you would like some in-person support.
Thank you.
Adam Baso (he/him/his/Adam), on behalf of the Content Transform Team
Director of Engineering
Wikimedia Foundation
[1] https://www.mediawiki.org/wiki/Parsoid
[2] https://www.mediawiki.org/wiki/Specs/HTML
[3] https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Updates
[4] https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2023