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[12].
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]: Special:OAuthConsumerRegistration
[12]: https://wikitech.wikimedia.org/wiki/API_Portal/Deprecation
--
Alexandra Paskulin
Technical Writer
Wikimedia Foundation
Hello everyone
If you don't use etherpad, you can ignore this message.
We will *delete all pads after 1st March 2026*! If you need any of your
pads, please make a local backup. We will not be able to recover the data
after 1st March.
The pad cleanup helps to reduce the size of the database and the footprint
on our infrastructure. After the cleanup, etherpad can still be used for
real-time collaboration but please do not expect long term storage.
Additional cleanups might happen after that unannounced.
See also https://phabricator.wikimedia.org/T415237 for more information.
Greetings and thank you
Jelto
Summary:
The Cloud Services implementation of Superset
(https://superset.wmcloud.org) is currently unsupported by WMF staff. We
would welcome a volunteer stepping up to maintain it, but without a new
home the service will be shut down at the end of March.
If you would like to take on ownership of this service, please reach out
to WMCS staffor comment on the phabricator task[1]. The day-to-day
maintenance load is minimal, but someone will need to keep track up
updates, security concerns and a potential future of defense against AI
scraping.
Background:
There has always been demand from researchers and volunteers to run
one-off queries against Wikimedia datasets. Quarry.wmcloud.org was built
and launched by the WMF more than 10 years ago. Originally a one-person
skunkworks project, it quickly caught on in popularity as one of the
most trafficked services run by Wikimedia Cloud Services.
A few years ago, we launched superset.wmcloud.org[0] as an intended
Quarry replacement. We soon learned that despite being a less polished,
home-made tool, Quarry provides many features that Superset does not,
and most users resisted migration away from it. Superset has only a
handful of active users.
At this point, Superset is essentially unsupported by WMF staff. As part
of ongoing efforts to improve our support for Toolforge and other more
popular services we will be either shutting it off or transferring
ownership of Superset in a few weeks[1].
[0] https://phabricator.wikimedia.org/T169452
[1] https://phabricator.wikimedia.org/T416373
Thumbnails shown on-wiki are already quantized to a set of standard sizes
(if a non-standard size is requested, the next-larger standard size is
used, and scaled to the requested size by the browser). We have recently
extended the set of standard sizes, and are now moving to only allow
standard sizes to be used. Regular editing and viewing will not be impacted
by this change at all.
* What isn't changing?
Thumbnails served on wiki (via the "thumb" argument to File:, and via the
Media API) will continue to behave as they do now - if you request a
non-standard size, the next-larger standard size will be provided, and
scaled in-browser if appropriate.
* What is changing?
Requests for non-standard thumbnail sizes using other methods (e.g.
constructing an upload.wikimedia.org URL with a non-standard thumbnail
size) will be blocked by our CDN. These are already being rate-limited for
requests that we assess are not coming from a web-browser.
During this quarter, we will be broadening the scope of the existing
rate-limiting and making it increasingly strict, with the aim being to
refuse such requests entirely by the end of March 2026.
* Why are WMF doing this?
Historically, we have generated thumbnails of whatever size was requested;
this has been a drain on our thumbnailing infrastructure and cost us in
network bandwidth and storage volume. With the increasing prevalence of
highly aggressive scrapers, this has become an intolerable burden on our
network, infrastructure, and staff, who have spent a lot of time over the
holiday period working hard to keep the wikis available for people to read
in the face of automated abuse.
* What do I need to do?
Most likely, nothing: we have already tracked down some of the more
widely-deployed sources of nonstandard thumbnail requests (e.g. Popups
extension) and fixed them. If you own or operate something that requests
thumbnails by constructing a thumbnail URI directly, then now is the time
to either use the Media API instead or to make sure you only request
standard thumbnail sizes.
* What are the standard thumbnail sizes?
They are: 20px, 40px, 60px, 120px, 250px, 330px, 500px, 960px, 1280px,
1920px, 3840px
They are defined in config as $wgThumbnailSteps -
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/…
And also documented on MetaWiki -
https://www.mediawiki.org/wiki/Common_thumbnail_sizes
To help fix the existing instances, please see
https://phabricator.wikimedia.org/T414805 for search-links, and examples of
how to fix them.
Best
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Earlier today (2026-03-30), all unmerged Gerrit patches to `mediawiki/core` that were both attached to a Phabricator task & were 2+ years old appear to have been abandoned _en masse_: [0]
There was a small amount of discussion after-the-fact in IRC (#wikimedia-releng): [1]
I am emailing wikitech-l to announce this myself, as it does not seem like this was done by the folks involved in making/actioning this decision. Speaking personally, I am saddened that it is apparently the case that there was no prior communication about today's action to the Wikimedia technical community, and that there was no (or, at least, no _recent_) consultation with the wider technical community prior to this highly impactful mass-action taking place.
From the current Gerrit search results at [2] (as viewed while typing this email - I'm not sure if Gerrit's search allows for filtering by the time a patch was abandoned), it appears that this action may have affected ~500-530 individual patches.
There was a Phabricator task filed in May 2025 that proposed the automatic abandonment of old changes; however, at the time of this action being taken, there had been no comments on that task since May 2025. [3]
Speaking personally again -- I wish that this hadn't happened. I wish there had been (wider, and more recent) community consultation. I wish that - at the very least - the voices expressing concern in the 'auto-abandonment' task [3] had been listened and responded to. That they weren't saddens me greatly: why should people take the time to express their concerns regarding suggested wide-scale changes such as this, if such concerns won't even be acknowledged prior to this sort of mass-action being taken?
Given (e.g.) the thesis quoted in Tyler Cipriani's comment at [4], I am also especially concerned about what this sort of action may mean for the future health of MediaWiki & other Wikimedia software projects.
I do now hope that these changes can be mass-restored, in the same way that they were mass-abandoned; at least, until further community discussion on the matter can take place. (But that, I recognise, is an opinion that not everyone may necessarily share.)
---
[0] https://sal.toolforge.org/log/QS3ePp0B8tZ8Ohr0YH3W
[1] https://wm-bot.wmcloud.org/browser/index.php?start=03%2F30%2F2026&end=03%2F…)
[2] https://gerrit.wikimedia.org/r/q/project:mediawiki/core+is:abandoned+before…
[3] https://phabricator.wikimedia.org/T393376
[4] https://phabricator.wikimedia.org/T393376#10831729
---
-- a smart kitten
https://phabricator.wikimedia.org/p/A_smart_kitten/