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
Yesterday, the MobileView Action API was removed from all Wikimedia
production servers [1].
The API was originally built to service our apps but over time that has
been replaced with the Page Content Service [2]. The original service was
not being maintained, and usage was very low. If you were using the
MobileView API we urge you to check this API out as it is a more powerful,
better cached alternative.
We marked the API as hard deprecated in December 2019 [3], after which it
was marked in ApiSandbox and in the response as deprecated, and support has
been dwindling since then, for example, the noimages parameter was dropped
in September 2020 [4].
In March 2022 we removed the remaining production blocker for removing the
code: language variant support [5]. The Page content service was
prreviously using the mobile view API for language variant views but has
now been rewired to use the better supported core action=parse API. If you
need to support language variant views and previously couldn't because of
the lack of support in the page content service this should no longer be an
obstacle..
Since April 2022 users of the API would have been seeing an inline banning
warning them of the upcoming breakage [6]. We got no feedback from these
banners so were comfortable with pushing forward.
Impact on user scripts was judged as low [7] with only 14 scripts impacted
so this has not been announced on tech news.
If you are impacted by this change, I apologise that previous
communications have failed you and I'd love to hear from you about how we
could have done this deprecation better. If I can support you in any way in
making sure your apps/gadgets/scripts are working again please feel free to
reply to this email either privately or publicly or to raise a topic on the
MobileFrontend talk page [8].
Finally, thanks to the engineers who helped make this deprecation possible.
Jon
[1] https://phabricator.wikimedia.org/T186627
[2] https://www.mediawiki.org/wiki/Page_Content_Service
[3] https://phabricator.wikimedia.org/T210808
[4] https://phabricator.wikimedia.org/T262580,
[5] https://phabricator.wikimedia.org/T236733
[6] https://phabricator.wikimedia.org/T286836
[7]
https://global-search.toolforge.org/?q=%5B%27%22%5C%3D%5Dmobileview®ex=1ā¦
[8]
https://www.mediawiki.org/wiki/Extension_talk:MobileFrontend?tableofcontentā¦
This message is a notice about forthcoming removal of a response field in
the REST APIās /page/summary endpoint. [1] This message was posted to
wikitech-l and is being cross-posted on mediawiki-api-announce.
The endpoint is used in the Page Previews (āhovercardsā) functionality on
the classic web (desktop) and Android & iOS experiences for Wikipedia, in
addition to numerous external experiences. We don't anticipate impacts on
the mainline Wikipedia experiences from this forthcoming field removal, as
the endpoint will still be operational.
The REST API's /page/summary endpoint provides an api_urls field in its
response with links to several other REST API endpoints supported by the
Page Content Service.
Three of the api_urls subfields refer to experimental endpoints that have
been removed from the REST API altogether in favor of newer API endpoints.
1. media (/page/media)
2. references (/page/references)
3. metadata (/page/metadata).
api_urls also contains subfields referring to stable endpoints that
continue to exist in the REST API:
1. summary (which is self referential)
2. edit_html (/page/html - the Parsoid HTML)
3. talk_html (/page/html/Talk:<title> - the Parsoid HTML for the
corresponding Talk page)
Wikimediaās Product Infrastructure team intends to remove the api_urls
field of the /page/summary response.
A cursory review at https://codesearch.wmflabs.org/ and Wikimedia Git
mirrors suggests api_urls isnāt in use in consuming code.
Review of web logs suggests traffic for the following endpoints:
- The media endpoint is at about 5% of its original traffic before its
decommission and it appears to be from old Wikipedia for Android clients.
This is expected.
- The references endpointās Wikipedia for Android traffic does not seem
present and its other traffic appears to be from non-user application
software based on User-Agent header components.
-The metadata endpointās traffic seems to have all but stopped.
This change is being announced in advance of the change because the
endpoint is advertised as stable. [2]
Please update your clients if you rely on the presence of the api_urls
field. If this change poses a problem for your clients, please do let us
know as soon as possible at the tracking task:
https://phabricator.wikimedia.org/T247991
We plan to remove the api_urls field described here on or after 14 July
2020.
Thank you.
Adam Baso
Director of Engineering
Wikimedia Foundation
[1]
https://en.wikipedia.org/api/rest_v1/#/Page%20content/get_page_summary__titā¦
[2] Refer to
https://www.mediawiki.org/wiki/API_versioning#End_point_stability and
https://www.mediawiki.org/wiki/Wikimedia_Product/Wikimedia_Product_Infrastrā¦
for more information on stability designations.