Hello,
In MediaWiki 1.42, within the list=tag API query module, the tag source
type named "extension" was renamed to "software" [1]. The "extension"
entries were made to still
appear alongside "software" in the tag source list but were deprecated
[2][3]. There are plans to remove this compatibility behavior in the
next major version of MediaWiki (1.47), so that the "extension" entries
will no longer appear.
The use of "extension" is misleading because 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.
[1] https://phabricator.wikimedia.org/T247552
[2]
https://en.wikipedia.org/w/api.php?action=query&list=tags&tgprop=source&tgl…
[3]
https://lists.wikimedia.org/hyperkitty/list/mediawiki-api-announce@lists.wi…
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
Forwarding this message from wikitech-l as it's also relevant to this list.
The the new API rate limits
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits> were deployed
as planned yesterday.
If you encounter any issues with these rate limits, please let us know.
Edge cases that are known to be potentially problematic include bots that
use owner-only tokens to authenticate but do not support cookies, gadgets
that make heavy use of the API, and external browser-based apps or games
that make a lot of API calls.
We have done our best to mitigate these and provide options, but please do
contact us at bot-traffic(a)wikimedia.org if you are unsure as to the best
path forward.
Best
Jonathan
---------- Forwarded message ---------
From: Jonathan Tweed <jtweed(a)wikimedia.org>
Date: Fri, 24 Apr 2026 at 10:36
Subject: Roll out of global API rate limits for identified requests
To: Wikitech-l <wikitech-l(a)lists.wikimedia.org>
Hi
We are now ready to start rolling out the next phase of global API rate
limits. As previously announced
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>,
this will apply to all API requests, including those that we class as
identified.
The full set of limits
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits> have now been
published on wiki, along with answers to frequently asked questions
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Rate_limits/FAQ> that we
received after the roll out of limits to anonymous requests. We will
gradually ramp down to the published limits, starting from next Tuesday
28th April. We expect to be at the final limits by the end of May.
As part of this change we have moved from per-hour limits to per-minute
limits, so please bear that in mind when you first look at the docs! This
is preferable, as it helps smooth aggregate request rates and also minimises
the impact on any user that inadvertently hits a limit.
These limits are based on extensive analysis of API request data, but it is
possible that some bots or gadgets may still trigger rate limits. We will
be actively monitoring all relevant spaces, so please do let us know if you
need help to work out the best way forward should this happen.
Thank you for your engagement with this. I hope from our actions it is
clear that we are not trying to limit community usage, but protect our
projects from automated usage at a scale we cannot support
<https://diff.wikimedia.org/2026/03/26/quo-vadis-crawlers-progress-and-whats…>
without ensuring it is a fair and sustainable use
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Responsible_Reuse>
of resources.
Best
Jonathan
--
Jonathan Tweed (he/him)
Senior Product Manager, Core Platform
Wikimedia Foundation
Good news, everyone!
A new Attribution API <https://www.mediawiki.org/wiki/Attribution_API>
module is now available as a beta
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Stability_policy> on all
Wikimedia Foundation hosted wiki projects. The purpose of this API is to
make it easier to appropriately attribute Wikimedia project content when
it’s presented or referenced in off-wiki contexts. This API directly
supports the Wikimedia Attribution Framework
<https://wikimedia-attribution.toolforge.org/>, which provides specific
guidelines for how to appropriately attribute content across different
reuse scenarios and form factors.
What does it do?
The Attribution API <https://www.mediawiki.org/wiki/Attribution_API>makes
it easy to follow the guidelines outlined in the Wikimedia Attribution
Framework <https://wikimedia-attribution.toolforge.org/>. The API provides
the information required by each attribution signal in a single,
well-structured and easy-to-use endpoint. Although the recommended
attribution information was largely already available through existing
APIs, this approach significantly simplifies the process for developers,
which we believe will make it more likely that developers will follow the
recommended standards.
Who is it for?
Appropriate attribution is critical for all reuse scenarios where Wikimedia
content will be presented off-wiki, as it ensures that the content is
fairly credited and that external readers remain aware of the Wikimedia
projects and communities it came from. This means that if you make games,
offer search services, use project content for research, build alternative
reader experiences, or contribute to anything else happening off-wiki, you
probably need to properly attribute Wikimedia content!
This specific API is also primarily intended for mission-supporting users
and use cases. Wikimedia Enterprise will offer similar information in their
structured responses for scaled commercial reuse.
How do I participate?
We encourage everyone to try out the endpoints and give us your feedback on
the project discussion page
<https://www.mediawiki.org/w/index.php?title=Talk:Attribution_AP>!
Additionally, if you discover what you think might be a bug, please feel
free to file an issue directly to the MediaWiki Interfaces Phabricator board
<https://phabricator.wikimedia.org/project/view/6931/>.
Major changes will minimally be announced on the project page
<https://www.mediawiki.org/wiki/Attribution_API>. If you are interested in
this capability, we recommend that you add the page to your watchlist to
stay informed with the latest changes and calls for targeted feedback. Some
of these changes may also be announced here or through Tech News, but the
nature of a beta does not guarantee broad communication of every change.
What should I expect?
This API is available on all Wikimedia projects, and is initially being
released as a beta
<https://www.mediawiki.org/wiki/Wikimedia_APIs/Stability_policy>. Reference
documentation can be found in the REST API sandbox
<https://www.mediawiki.org/w/index.php?title=Special:RestSandbox&api=attribu…>
on any Wikimedia wiki (such as the REST API sandbox on English Wikipedia
<https://en.wikipedia.org/w/index.php?api=attribution.v0-beta&title=Special%…>).
Although available everywhere, the Attribution API only explicitly supports
Wikipedia articles and media files hosted through either Wikipedia or
Commons. We need your help testing and shaping additional project and
content types to help inform how the information should be structured.
We are continuing to iterate and refine the API. Although we expect the
interface itself to remain relatively stable, the specific returned values
are subject to change over time. Breaking changes to adjust the interface
or response structures may also occur during the beta period as we respond
to emerging feedback and feature requests.
Following the beta period, we will elevate the API to a stable v1. This
will be done after we are satisfied with meeting user expectations and when all
high priority issues are resolved. Although there is not yet a firm date
for when we will elevate this experience, we expect it to happen around
September 2026, depending on the nature of requests that arise during the
beta period. Additional communications will happen closer to the stable
version launch date to ensure the community is aware of the upcoming change.
Please feel free to reach out directly here or post on the project
discussion page
<https://www.mediawiki.org/w/index.php?title=Talk:Attribution_AP> if you
have any questions, comments or concerns! We look forward to your feedback
and support in helping us refine this API, as well as the beta process
itself.
Thanks, and happy attribution!
Halley
*Halley Coplin* (she/her)
Sr. Product Manager, MediaWiki Interfaces
Wikimedia Foundation <https://wikimediafoundation.org/>
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/>