Developer Portal/Version 2

Group:	See #Working group
Start:	2026-06
Backlog:	phab:tag/Wikimedia-Developer-Portal
Lead:	User:HCoplin-WMF

Help shape the future of the Developer Portal
The Wikimedia Foundation is looking for volunteers to participate in interviews and provide feedback on the next version of the Developer Portal. Sign up to participate

This page provides information about the project to expand the functionality of the Wikimedia Developer Portal (developer.wikimedia.org).

Project summary

Version 2 is an initiative to expand Wikimedia's existing developer portal. The goal is to create a single, authoritative entry point that makes it significantly easier for all Wikimedia developers, including technical community members, researchers, and external reusers, to discover the right APIs for their use case, understand what is expected of them, and get started quickly.

This project will build on the ideas behind the existing developer portal, preserving its role as a way-finding resource for our diverse technical contributor community while adding an interactive API explorer and information about API policies and best practices.

Project overview

Status: as of June 2026

Document owner: Halley Coplin (HCoplin-WMF)
Part of: PP3 - Scalable System for Responsible Reuse
Project nickname: Unified Developer Front-Door, Project Frodo

Working group

Team	Members
MediaWiki Interfaces	Halley Coplin, Moriel Schottlender
Technical Documentation	Alexandra Paskulin, Tricia Burmeister, Kamil Bach
Design	Sarai Sanchez
Wikimedia Enterprise	Jolan Wuytz, Chuck Reynolds

Background

Wikimedia's API ecosystem has grown significantly over the years. Today, technical contributors, researchers, and external reusers access a wide variety of APIs, documentation resources, and tooling spread across MediaWiki, Wikitech, Meta, doc.wikimedia.org, the (soon to be deprecated) API Portal, and the developer portal itself.

Feedback gathered through the developer satisfaction survey and multiple API listening tours has consistently highlighted two top pain points:

Only 54% of developers agree that documentation is easy to find.
Only 43% agree that it is clear which API to use for their needs.

These findings reflect a broader structural challenge: our API offerings are fragmented across many inconsistent documentation experiences, making it difficult for developers (especially newcomers) to know where to start, what is recommended, and what is expected to conform with standards for responsible reuse.

Problem statement

Developers who want to build tools, bots, scripts, or data-driven applications using Wikimedia content face a high barrier to entry. Even motivated contributors frequently give up or end up building on the wrong foundation simply because:

It is unclear what APIs exist and which are recommended for a given use case.
Key documentation is scattered across multiple wiki projects and off-wiki solutions with different quality, expected levels of knowledge, and styles.
API policy and etiquette expectations are not surfaced clearly within the developer journey; developers encounter them too late, frequently after a violation, if at all.
Although the REST and Action API Sandboxes offers a way to explore API endpoints interactively, they are hard to discover.
The overall developer experience varies widely depending on which entry point a developer happens to land on first.

This creates unnecessary friction for community members who want to do the right thing, and makes it harder to grow and sustain a healthy developer ecosystem.

Goals and outcomes

Version 2 aims to:

Improve discoverability: Make it easy for any developer to find the APIs and tools most relevant to their use case, starting from a single, reliable entry point.
Guide developers earlier: Improve onboarding so developers can self-select into the right technical pathway before building, reducing the need for later redirection or rebuilding.
Surface policy and etiquette clearly: Integrate API access policies, rate limit guidance, and best practices directly into the developer journey. It should be easy to do the right thing.
Lower the barrier to entry: Meet modern developer expectations with guided onboarding, an interactive API explorer, and clear getting-started guides.
Improve developer satisfaction: Address the top pain points surfaced through the developer satisfaction survey — documentation discoverability and clarity about which API to use.
Grow the technical contributor community organically: By reducing friction for new developers and making Wikimedia's technical ecosystem more approachable, the portal aims to increase the number of developers who successfully make their first API call and go on to build tools for our communities.
Apply Wikimedia brand styles: Redesign the Dev Portal to use Wikimedia brand styles and components, providing the same look and feel as other Wikimedia sites.

Success metrics

A 2x increase in human page views within four weeks of a v2 launch in January-March 2027, relative to the current developer.wikimedia.org baseline.
Measurable increase in new developer registrations and token requests originating from the portal.
Improved scores on documentation discoverability and API clarity in the annual developer satisfaction survey.
Increase in page views for API policy and access documentation.

Scope overview

The portal is being designed as an evolution of developer.wikimedia.org, not a replacement for on-wiki documentation. The approach is hybrid: the most impactful and commonly accessed content will be available natively within the portal, while complementary and community-authored documentation will continue to live on-wiki with clear way-finding from the portal.

What will be included natively

Onboarding: Opinionated getting-started paths for different types of developers (ie: community tool builders, bot authors, on-wiki script authors, researchers).
Interactive API explorer: A sandbox where developers can browse a curated set of REST API modules, view reference documentation, and make test calls against real wiki projects.
API policy and etiquette documentation: Key policy pages surfaced directly within the developer journey, with links to authoritative on-wiki sources.
Authentication guidance: Clear documentation on how to request tokens and authenticate API requests, with improved token management tools.
Changelog and migration guides: A unified view of API changes and guidance for developers maintaining existing integrations.

What will remain on-wiki

Tutorials and step-by-step guides (with community contribution encouraged and curated highlights featured in the portal).
Extension-specific and MediaWiki-specific documentation.
Policy pages that are authoritative on-wiki (the portal will transclude or link to these, rather than duplicating them).
API reference documentation and sandboxes for APIs that do not yet meet our API standards.

Key design decisions

The portal will be off-wiki to support a more modern, flexible experience. This includes a modern, interactive API explorer, clean per-endpoint URLs for improved search discoverability, and centrally managed reference documentation that doesn't fit the wiki model well.
Community contributions remain valued. Rather than open wiki editing for technical reference documentation, the contribution model will lean into volunteer-created tutorials and examples, with an editorial process for highlighting the relevant and high quality content within the portal. Reference documentation will be maintained by the API owning teams directly and subjected to a centrally managed review process to ensure accuracy, as well as quality and tone consistency.
The portal will promote a curated set of APIs as the preferred pathway for new integrations, while ensuring that the suite of existing APIs (ie: the Action API) remain discoverable for use cases they uniquely support.
Translation and language support are first-class requirements. Interface strings will be managed through translatewiki.net-compatible tooling; content translation will be supported with appropriate fallbacks.

What's next

Timeline


Milestone	Description	Estimated completion date	Phabricator task
Technical design	If we create an actionable technical design document, we can proceed with the implementation of the unified front door development portal.
Information architecture	If we design an information architecture for the expanded, unified developer portal, we can establish preferred API pathways for technical contributors and content reusers while continuing to meet the information needs of user journeys served by the existing developer portal.	September 30, 2026	phab:T431332
Adoption baseline	If we begin measuring and differentiating likely human traffic to the existing developer portal, we will be able to set a baseline for developer engagement, which we can then use to measure renewed interest and adoption of the new version.
User validation	If we validate low-fidelity mockups of the unified developer portal with prospective users, we will be able to test our assumptions, identify gaps in the proposed experience, and refine the solution to better meet real user needs.

Get involved

We are actively seeking community input and feedback, particularly from developers who have experienced pain points with the current documentation landscape. If you have thoughts on:

What you wish existed when you started building with Wikimedia APIs
Pain points in discovering or navigating existing documentation
Interest in contributing tutorials, examples, or translations

Please share your feedback on the talk page, or join the discussion in the relevant channels listed on the Communication page.