Attribution API
|
The Attribution API makes it easier to fairly credit Wikimedia content wherever it is used. The API provides access to data for attribution signals for an article or media file.
Documentation
[edit]Reference
[edit]- Reference documentation can be found in the REST API sandbox on any Wikimedia wiki (such as the REST API sandbox on English Wikipedia).
Concepts
[edit]Quick start
[edit]# Get attribution information for the Earth article from English Wikipedia
curl 'https://en.wikipedia.org/w/rest.php/attribution/v0-beta/pages/Earth/signals'
API features
[edit]Attribution signals are the individual elements that keep Wikimedia projects visible when their content is surfaced in external contexts. Signals provide direct acknowledgment of and access to sources, and present additional information that helps end users evaluate and engage with the knowledge they encounter.
The Attribution API offers the following key features:
- Provide well-structured attribution signals for content across Wikimedia projects.
- Empower developers to clearly identify Wikimedia projects as the source of knowledge in external contexts.
- Help reusers do their part in sustaining the Wikimedia ecosystem by driving engagement back to the source of free knowledge.
Supported project and content types
[edit]Wikimedia project support
[edit]The API is technically available on all Wikimedia projects and can be used to pull information for any page. However, only Wikipedia articles and media files hosted through Commons or Wikipedia projects are fully supported at this time. This means that other project and content types are more likely to have inaccurate or incomplete information returned.
We encourage users to test on additional projects and provide feedback or make suggestions to improve support for additional project types on the discussion page.
MediaWiki availability
[edit]This API is built within the WikimediaCustomizations extension and relies on Wikimedia-specific services, meaning it is not available for MediaWiki instances outside of Wikimedia.
Usage disclaimer
[edit]While this API is designed to make attribution easier, we cannot fully guarantee the completeness or accuracy of the data returned. Due to the human nature of Wikimedia projects, there may be cases where the available data may be incomplete or inaccurate. Content reusers are still ultimately responsible for ensuring that what is presented meets all applicable license requirements and reflects fair reuse as defined in the Wikimedia attribution framework.
Beta availability
[edit]The Attribution API will first be made available as a beta module. More information about the beta audience can be found in the Wikimedia API Stability policy. After completion of the beta, the Attribution API will be elevated to an official v1.
Timing
[edit]The beta version is expected to launch on or before April 21st. The beta feedback period will last for at least three months, with a v1 expected around September 2026.
Known issues
[edit]We are currently aware of the following issues:
| Title | Description | Status | Phabricator | ECD |
|---|---|---|---|---|
| Improve consistency for returned license names | Licenses are manually configured within individual Wikimedia projects, resulting in inconsistent values. The Attribution API will normalize these values to match the officially supported versions defined by Creative Commons. | In Progress | T421051 | May, 2026 |
| Support remote media | Users have multiple options for uploading and embedding files within Wikipedia articles. While this complexity is hidden through the UI by dynamically fetching files from either Commons or the local wiki, this flexibility is not yet supported in the Attribution API. | Pending | T421060 | May, 2026 |
| 'contributor_counts' not yet implemented | The 'contributor_counts' field within the 'trust_and_relevance' object is not yet implemented. It is currently returning null by design. WE5.2.14 focuses on creating a data pipeline to calculate and deliver this value more reliably. | Pending | July, 2026 | |
| 'relative' trending not yet implemented | Only the 'top' trending indicator is currently implemented. Although we expect the interface to remain stable, relative trending is hardcoded to return false until fully implemented. A future hypothesis will cover creating a data pipeline to calculate and deliver this value. | Pending | September, 2026 | |
| Hard-coded calls to action | The existing calls to action are currently hard-coded for demonstrative purposes only. Although we expect the interface to remain fairly stable after implementation, the specific values returned should be used with caution in any production level implementations. Specific implementation plans are pending, following developer and staff feedback. | Pending | TBD |
Potential improvements
[edit]| Title | Description | Status | Phabricator | ECD |
|---|---|---|---|---|
| Create endpoint to pull attribution information for all images contained on Wikipedia articles | Wikipedia articles increasingly feature media files, particularly images. Creating an endpoint that allows callers to request the attribution information for all embedded images will make it easier to properly attribute that embedded content. | Awaiting prioritization | T424037 | TBD |
| Return license brand marks | Some users are expressing interest in returning the license brand mark (like the Creative Commons logo) in addition to the Wikimedia brand mark logos. To make it easier, we can return the logos on their behalf, as part of the standard license response body. | Awaiting prioritization | T421897 | TBD |
| Additional brand mark availability | We currently only return the actively featured logos and brandmarks for the Wikimedia project. However, some off-wiki experiences may want additional versions, such as iconography specifically designed for light or dark backgrounds. | Discovery | TBD |
Access policy
[edit]See the access policy for Wikimedia APIs.
Stability policy
[edit]See the stability policy for Wikimedia APIs.
Provide feedback
[edit]During the beta period, we welcome feedback from technical contributors, partners, and Wikimedia Foundation staff. Questions, comments, and feature requests should be raised on the discussion page. Bugs that are not currently tracked below may be filed directly to Wikimedia Phabricator and tagged with MW-Interfaces-Team.
Get help
[edit]- Maintained by the MediaWiki Interfaces Team.
- Live chat (IRC): #mediawiki-core connect
- Issue tracker: Phabricator MediaWiki-REST-API (Report an issue)
Project background
[edit]This project is part of the WE5.3 key result within the FY25-26 annual plan. WE5.3 focuses on creating an attribution framework. The framework is designed to:
- Ensure that content reusers meet the requirements set by Wikimedia content licenses.
- Surface Wikimedia project brands to promote content trust and continually build brand awareness across distributed ecosystems.
- Amplify signals that may motivate users to engage with Wikimedia's mission directly as a reader, contributor, or donor.
Problem statement
[edit]Although many of the identified attribution requirements and trust signals are technically available through existing APIs, the developer experience to get them is far from perfect. The pre-existing workflows put too much responsibility on clients to work across many endpoints and make implementation judgment calls to stitch together what is ultimately required or recommended through the framework. Additionally, by leveraging existing endpoints, it prevents the Wikimedia Foundation from understanding who is engaging with and adhering to the framework's recommendations; this is because the endpoints are likely already being utilized for other use cases, and we would not be able to explicitly differentiate the attribution usage.
Goals and outcomes
[edit]The main goal of the Attribution API is to make it as easy as possible for external developers to appropriately attribute Wikimedia content.
- Increased adoption: The easier we make fetching data to support attribution, the more likely partners and community members are to actually adopt the recommended signals. Particularly in our situation, where the content is freely available through open licensing, we are ultimately asking developers to follow these standards out of a sense of goodwill. Removing friction will increase the chances that partners and community tools will adopt all signals, instead of simply ignoring or cherry-picking the most straightforward or minimum license required signals from the list.
- Adoption observability: By creating dedicated endpoints, we can more directly observe and monitor adoption. The current approach of offering a smattering of existing solutions will make it difficult to differentiate who is using data for attribution purposes versus those who are using the data for other purposes. Additionally, dedicated endpoints will more easily support future enhancements like supporting conversion tracking more natively.
- Flexibility through abstraction: By creating an API contract that is abstracted from the backend, we are able to maintain a consistent interface for callers while enabling flexibility on the backend to change how we calculate certain values. For example, we may want to change how contributors are tallied over time, with outstanding decisions for whether we include bots as editors, reverted changes, and other nuanced interpretations of what 'contributor' means.
- Improved developer experience: The current experience relies heavily on client-side parsing and business logic to get to the final signals. That makes it difficult for external developers to implement and ultimately maintain, particularly in cases where they are expected to parse HTML or rely on general-purpose endpoints that may change over time. A dedicated API will allow us to take a more direct and opinionated approach to the signals themselves, while also making it easier for content reusers to adopt them.
- Developer feedback: Rapid delivery of initial endpoints through a beta API module will allow partners to engage more quickly with the recommendations, which will lead to faster and more meaningful feedback loops. This feedback will allow us to improve both the API and the attribution framework itself, including refining the definitions of specific signals.