Page MenuHomePhabricator

Shut down the API Portal
Closed, ResolvedPublic

Description

Hypothesis owner: @apaskulin
Hypothesis owner delegate: @HCoplin-WMF
Start date: April 6, 2026
Target completion date: June 30, 2026
Actual completion date: June 30, 2026
Hypothesis ID: 5.2.11b

If we complete API Portal documentation migration, we will be able to fully deprecate the API Portal system, which will simplify API documentation discovery, increase documentation consistency, and reduce the number of API support systems.

Scope

In scope:

  • Documentation on api.wikimedia.org
  • Documentation for APIs available through api.wikimedia.org

April-June project plan

Next steps:

April-June outcomes

API Portal components

API Portal components:

Related components:

Background

In 2020, the Wikimedia Foundation Platform Engineering Team wanted to create a home for Wikimedia API docs that was similar to other popular API docs sites, and that allowed developers to more easily create and manage API keys.

Building the API Portal as a standalone wiki benefits from the advantages of MediaWiki:

  • Ease of editing
  • Ability to translate content
  • Community collaboration through talk pages, watchlists, and other features

However, using a standalone wiki for the API Portal also has disadvantages:

  • Administration: Each new wiki needs a community of administrators, page patrollers, and other functionaries. A new wiki adds work for the Wikimedia technical community.
  • Technical complexity: MediaWiki is a complex ecosystem. Since the API Portal works differently from other Wikimedia wikis, we often find bugs that come from interactions with extensions, skins, and other wikis.
  • Visual inconsistency: The API Portal’s simplified visual design makes it difficult to access wiki features like special pages. In addition, global skin preferences can override the API Portal’s visual design entirely, making the site difficult to use.

Wikimedia Foundation’s Product Management, MediaWiki Interfaces, and Tech Docs teams have decided that the disadvantages of implementing the API Portal as a standalone wiki outweigh the advantages. We’re still working on exact plans and schedules for shutting down the Portal, but here is a general idea of what to expect:

  • Endpoints: api.wikimedia.org endpoints will continue to work as currently documented until at least June 2026. Starting in the second half of 2026, api.wikimedia.org endpoints will be migrated to new routes and eventually deprecated.
  • API keys: Most API keys created through the API Portal will continue to work. You can manage your API keys through Special:OAuthConsumerRegistration on Meta-Wiki.
  • Docs: Documentation from the API Portal will be consolidated and moved to other technical documentation wikis.

Information architecture

  • mw:Wikimedia APIs – main landing page for Wikimedia APIs
  • mw:Wikimedia APIs/subpages – topics that apply to multiple APIs
  • mw:[API name] API – landing pages for an individual API
  • mw:[API name] API/subpages – topics that apply to an individual API
  • mw:[tutorial name] – API tutorials
  • wikitech:API Portal/Deprecation – Information about deprecated api.wikimedia.org functionality. We can use this as an intermediary source of information to direct users to docs for API Portal APIs that are available elsewhere.

All APIs in the collection will have a landing page on mediawiki.org that uses this structure for consistency, but if those docs already exist on another wiki, the docs themselves can remain there instead of being migrated to mediawiki.org.

Links to the API Portal on other wikis

January-March hypothesis

Hypothesis owner: @apaskulin
Hypothesis owner delegate: @HCoplin-WMF
Start date: January 12, 2026
Target completion date: March 27, 2026
Actual completion date: April 2, 2026
Hypothesis ID: WE5.2.11

If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.

January-March project plan

January-March outcomes

Resources

Related Objects

StatusSubtypeAssignedTask
Resolved apaskulin
Resolved apaskulin
Resolved apaskulin
Resolved apaskulin
Resolved apaskulin
ResolvedNone
In ProgressClement_Goubert
ResolvedClement_Goubert
ResolvedClement_Goubert
ResolvedBUG REPORTClement_Goubert
ResolvedMarostegui
OpenPRODUCTION ERRORSTran
DeclinedPRODUCTION ERRORNone
OpenClement_Goubert
ResolvedClement_Goubert
ResolvedReedy
ResolvedKBach
DuplicatePRODUCTION ERRORNone

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

After discussion with @Ladsgroup, we'll be closing the wiki before T418492: Redirect API Portal wiki URLs to www.mediawiki.org/wiki/Wikimedia_APIs.
The plan is now as follows:

Prerequisites:

  • The API portal wiki is dumped, and the dump is durably stored on dumps.wikimedia.org
  • The reminders have been sent out and we're ready for the API portal wiki to become read-only

Steps

  1. Close apiportalwiki, it is now read-only except for stewards
  2. T418492: Redirect API Portal wiki URLs to www.mediawiki.org/wiki/Wikimedia_APIs, apiportalwiki is now unreachable and all non-API calls to apiportalwiki are HTTP 301 (Moved Permanently) to www.mediawiki.org/wiki/Wikimedia_APIs
  3. Once satisfied we won't want to reopen apiportalwiki for any reason, T418494: Delete the API Portal wiki and drop its database. The data is now irrecoverable except from backups and the last dump.
  4. Uninstall the custom skins and extensions used only by apiportalwiki

Potential issues

  • Some maintenance scripts, periodic jobs, or jobrunner jobs may fail during the period where apiportalwiki is closed and unreachable. These should be easily identifiable.
  • Behaviour of MediaWiki APIs under api.wikimedia.org (/core et al.) once the wiki is closed/deleted needs to be checked.

A small suggestion on the order of steps in Clement's comment. Perhaps the dump should occur after the wiki is set to read only. Edits -> freeze -> snapshot, instead of snapshot -> edits -> freeze.

@Clement_Goubert That sounds good to me! I'll let you know about the schedule once the Lift Wing API docs are migrated.

@Novem_Linguae I'm not sure how feasible it is to take a snapshot at a specific time, but I can follow-up with the dumps team and check.

I haven't reviewed the whole task tree, but is there a planned step to replace the custom skin with something we generally use such as vector-2022 as part of the decomm process? It would be nice to be able to drop and archive the wikimediaapiportal skin (T259661: Restrict skin options on API Portal Beta Site) rather than carry it indefinitely as baggage in the train.

I haven't reviewed the whole task tree, but is there a planned step to replace the custom skin with something we generally use such as vector-2022 as part of the decomm process? It would be nice to be able to drop and archive the wikimediaapiportal skin (T259661: Restrict skin options on API Portal Beta Site) rather than carry it indefinitely as baggage in the train.

  1. Once satisfied we won't want to reopen apiportalwiki for any reason, T418494: Delete the API Portal wiki and drop its database. The data is now irrecoverable except from backups and the last dump.
  2. Uninstall the custom skins and extensions used only by apiportalwiki

It looks like the answer to my question was already here in the full shutdown plan. I didn't consider that an actual delete would be done vs what I know more normally as moving to the closed group but staying online like https://aa.wikipedia.org/wiki/Main_Page. Sorry for the noise.

A small suggestion on the order of steps in Clement's comment. Perhaps the dump should occur after the wiki is set to read only. Edits -> freeze -> snapshot, instead of snapshot -> edits -> freeze.

After checking with the dumps team, it is possible to take a snapshot at a specific time, but it would require a manual process. Since I don't expect any significant updates to the wiki between the last automated dump on June 1 and the day the wiki enters read-only mode and since I expect the number of people interested in a dump of the wiki to be extremely small, I don't think it's worth asking the team to do a manual dump. The dump from June 1 will contain all essential content and revision history.

MariaDB [meta_p]> select is_closed from wiki where dbname = 'apiportalwiki';
+-----------+
| is_closed |
+-----------+
|         0 |
+-----------+
1 row in set (0.001 sec)

Please urgently set is_closed to 1 in the wiki table. Bots and tools use this table to find wikis. The unexpected redirect to a wiki page for Action API requests wreaks havoc, at least for some of my tools.

Is this in wikireplicas? I think meta_p is in two different clouddbs, I will find them.

This was not enough:

fnegri@clouddb1018:~$ sudo maintain-meta_p --all-databases
[...]
root@clouddb1018:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
+-----------+
| is_closed |
+-----------+
|         0 |
+-----------+
1 row in set (0.001 sec)

Set it manually in SQL:

root@clouddb1018:s7[(none)]> UPDATE meta_p.wiki SET is_closed=1 where dbname = 'apiportalwiki';
Query OK, 1 row affected (0.001 sec)
Rows matched: 1  Changed: 1  Warnings: 0

root@clouddb1018:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
+-----------+
| is_closed |
+-----------+
|         1 |
+-----------+
1 row in set (0.000 sec)

Did the same in clouddb1014:

root@clouddb1014:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
+-----------+
| is_closed |
+-----------+
|         0 |
+-----------+
1 row in set (0.001 sec)

root@clouddb1014:s7[(none)]> UPDATE meta_p.wiki SET is_closed=1 where dbname = 'apiportalwiki';
Query OK, 1 row affected (0.000 sec)
Rows matched: 1  Changed: 1  Warnings: 0

root@clouddb1014:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
+-----------+
| is_closed |
+-----------+
|         1 |
+-----------+
1 row in set (0.000 sec)

This was not enough:

Apparently I needed to add --purge.

I've just run this on both clouddb1014 and clouddb1018, to make sure everything is consistent:

sudo maintain-meta_p --all-databases --purge

This deleted the row completely:

root@clouddb1014:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
Empty set (0.000 sec)

root@clouddb1018:s7[(none)]> select is_closed from meta_p.wiki where dbname = 'apiportalwiki';
Empty set (0.000 sec)

@Count_Count can you confirm the problem is resolved for your tools?

@Count_Count can you confirm the problem is resolved for your tools?

Yes, https://spamcheck.toolforge.org/ came up by itself just now. Much obliged!

apaskulin updated the task description. (Show Details)