 | Wikidata For Developers: Data access |
Wikidata currently contains over 110 million Items and over 1,3 million Lexemes, and these numbers will keep on growing. There are many methods available to access all that data—this document lays them out and helps prospective users choose the best method to suit their needs.
It's crucial to choose an access method that gives you the data you need in the quickest, most efficient way while not putting unnecessary load on Wikidata; this page is here to help you do just that.
Wikidata offers a wide range of general data about everything under the sun. All that data is licensedCC0, "No rights reserved", for the public domain.
Changes to APIs and other methods of accessing Wikidata are subject to theStable Interface Policy. Data sources on this page arenot guaranteed to be stable interfaces.
This document is about accessing data from outside Wikimedia projects. If you need to present data from Wikidata in another Wikimedia project, where you can employ parser functions, Lua and/or other internal-only methods, refer toHow to use data on Wikimedia projects.
We offer the data in Wikidata freely and with no requirement for attribution underCC-0. In return, we would greatly appreciate it if, in your project, you mention Wikidata as the origin of your data. In so doing you help ensure that Wikidata will stay around for a long time to provide up-to-date and high-quality data. We also promote the best projects that use Wikidata's data.
Some examples for attributing Wikidata: "Powered by Wikidata", "Powered by Wikidata data", "Powered by the magic of Wikidata", "Using Wikidata data", "With data from Wikidata", "Data from Wikidata", "Source: Wikidata", "Including data from Wikidata" and so forth. You can also use one of ourready-made files.
You may use the Wikidata logo shown above, but in so doing you should not in any way imply endorsement by Wikidata or by the Wikimedia Foundation.
Please offer your users a way to report issues in the data, and find a way to feed this back to Wikidata's editor community, for example through theMismatch Finder. Please share the location where you collect these issues on theProject chat.
When accessing Wikidata's data, observe the following best practices:
Accept-Encoding: gzip,deflate and don’t make too many requests at once.maxlag parameter and consult the rest of the guidelines laid out inAPI:Etiquette.Wikidata offers anElasticsearch index for traditional searches through its data:Special:Search
Use search when you need to look for a text string, or when you know the names of the entities you're looking for but not the exact entities themselves. It's also suitable for cases in which you can specify your search based on some very simple relations in the data.
Don't use search when the relations in your data are better described as complex.
You can make your search more powerful with these additional keywords specific to Wikidata:haswbstatement,inlabel,wbstatementquantity,hasdescription,haslabel. This search functionality is documentedon the CirrusSearch extension page. It also has its ownAPI action.
The Linked Data Interface provides access to individual entities via URI:http://www.wikidata.org/entity/Q???. Such URIs are called concept URIs. Note concept URIs use HTTP, not HTTPS.
Use the Linked Data Interface when you need to obtain individual, complete entities that are already known to you.
Don't use it when you're not clear on which entities you need – first try searching or querying. It's also not suitable for requesting large quantities of data.
Each Item or Property has a persistentURI made up of the Wikidata concept namespace and the Item or Property ID (e.g.,Q42,P31) as well as concrete data that can be accessed by that Item's or Property's dataURL.
The namespace for Wikidata's data about entities ishttps://wikidata.org/wiki/Special:EntityData.
Appending an entity's ID to this prefix (you can use/entity/ for short) creates the abstract (format-neutral) form of the entity's data URL. When accessing a resource in the Special:EntityData namespace, the special page appliescontent negotiation to determine the output format. If you opened the resource in a browser, you'll see an HTML page containing data about the entity, because web browsers prefer HTML. However, a linked-data client would receive the entity data in a format like JSON or RDF – whatever the client specifies in its HTTPAccept: header.
http://www.wikidata.org/entity/Q42When you need to bypass content negotiation, say, in order to view non-HTML content in a web browser, you can specify the format of the entity data by appending the corresponding extension to the data URL; examples include.json,.rdf,.ttl,.nt or.jsonld. For example,https://www.wikidata.org/wiki/Special:EntityData/Q42.json gives you Item Q42 in JSON format.
By default, the RDF data that the Linked Data interface returns is meant to be complete in itself, so it includes descriptions of other entities it refers to. If you want to exclude that information, you can append the query parameter?flavor=dump to the URL(s) you request.
By appending&flavor= to the URL, you can control exactly what kind of data gets returned.
?flavor=dump: Excludes descriptions of entities referred to in the data.?flavor=simple: Provides only truthy statements (best-ranked statements withoutqualifiers orreferences), along with sitelinks and version information.?flavor=full (default): An argument of "full" returns all data. (You don't need to specify this because it's the default.)If you want a deeper insight into exactly what each option entails, you can take a peek into thesource code.
You can request specific revisions of an entity with therevision query parameter:https://www.wikidata.org/wiki/Special:EntityData/Q42.json?revision=112.
The following URL formats are used by the user interface and by the query service updater, respectively, so if you use one of the same URL formats there’s a good chance you’ll get faster (cached) responses:
The Wikidata Query Service (WDQS) is Wikidata's own SPARQL endpoint. It returns the results of queries made in the SPARQL query language:https://query.wikidata.org
Use WDQS when you know only the characteristics of your desired data.
Don't use WDQS for performing text or fuzzy search – FILTER(REGEX(...)) is an antipattern. (Usesearch in such cases.)
WDQS is also not suitable when your desired data is likely to be large, a substantial percentage of all Wikidata's data. (Consider using adump in such cases.)
You can query the data in Wikidata through our SPARQL endpoint, theWikidata Query Service. The service can be used both as an interactive web interface, or programmatically by submittingGET orPOST requests tohttps://query.wikidata.org/sparql.
The query service is best used when your intended result set is scoped narrowly, i.e., when you have a query you're pretty sure already specifies your resulting data set accurately. If your idea of the result set is less well defined, then the kind of work you'll be doing against the query service will more resemble a search; frequently you'll first need to do this kind of search-related work to sharpen up your query. See theSearch section.
The query service at query.wikidata.org only contains the main graph of Wikidata. The Items related to scholarly articles are in a separate query service at query-scholarly.wikidata.org. For more details seeWikidata:SPARQL query service/WDQS graph split.
The Linked Data Fragments (LDF) endpoint is a more experimental method of accessing Wikidata's data by specifying patterns in triples:https://query.wikidata.org/bigdata/ldf. Computation occurs primarily on the client side.
Use the LDF endpoint when you can define the data you're looking for using triple patterns, and when your result set is likely to be fairly large. The endpoint is good to use when you have significant computational power at your disposal.
Since it's experimental, don't use the LDF endpoint if you need an absolutely stable endpoint or a rigorously complete result set. And as mentioned before, only use it if you have sufficient computational power, as the LDF endpoint offloads computation to the client side.
If you have partial information about what you're looking for, such as when you have two out of three components of your triple(s), you may find what you're looking for by using theLinked Data Fragments interface athttps://query.wikidata.org/bigdata/ldf. See theuser manual andcommunity pages for more information.
The Wikibase REST API is an OpenAPI-based interface that allows users to interact with, retrieve and edit items and statements on Wikibase instances – including of course Wikidata:Wikidata REST API
The Wikibase REST API is still under development, but for Wikidata it's intended to functionally replace theAction API as it's a dedicated interface made just for Wikibase/Wikidata.
The use cases for the Action API apply to the Wikibase REST API as well. Use it when your work involves:
Don't use the Wikibase REST API when your result set is likely to be large. (Consider using adump in such cases.)
It's better not to use the Wikibase REST API when you'll need to further narrow the result of your API request. In such cases it's better to frame your work as asearch (for Elasticsearch) or aquery (for WDQS).
The Wikibase REST API hasOpenAPI documentation usingSwagger. You can also review thedeveloper documentation.
The Wikidata API is MediaWiki's own Action API, extended to include some Wikibase-specific actions:https://wikidata.org/w/api.php
Use the API when your work involves:
Don't use the API when your result set is likely to be large. (Consider using adump in such cases.)
The API is also poorly suited to situations in which you want to request the current state of entities in JSON. (For such cases consider using theLinked Data Interface, which is likelier to provide faster responses.)
Finally, it's probably a bad idea to use the API when you'll need to further narrow the result of your API request. In such cases it's better to frame your work as asearch (for Elasticsearch) or aquery (for WDQS).
The MediaWiki Action API used for Wikidata is meticulously documentedon Wikidata's API page. You can explore and experiment with it using theAPI Sandbox.
There are multiple Wikibase specific endpoints. Here is an example request:
You can also access the API by using a bot. For more on bots, seeWikidata:Bots.
The Recent Changes stream provides a continuous stream of changes of all Wikimedia wikis, including Wikidata:https://stream.wikimedia.org
Use the Recent Changes stream when your project requires you to react to changes in real time or when you need all the latest changes coming from Wikidata – for example, when running your own query service.
The Recent Changes stream contains all updates from all wikis using theserver-sent events protocol. You'll need to filter Wikidata's updates out on the client side.
You can find the web interfaceat stream.wikimedia.org and read all about it on theEventStreams page.
The Wikidata Vector Database stores high-dimensional vector representations of Wikidata entities. It enables semantic search based on meaning and context rather than keyword matching, and supports natural-language queries against entities.
Use vector search for exploration purposes, for example, when you want to uncover entities without explicitly knowing their labels, or when you need to narrow a search down to a smaller, more relevant subgraph of Wikidata as a starting point for further research before moving on to more structured tools.
The vector database can also be used in AI/ML pipelines, such as enabling semantic search in RAG workflows or applying vector distances to tasks like classification and other types of analysis.
You can find more information on theWikidata Vector Database page. The Wikidata Vector Database is available atwd-vectordb.wmcloud.org, and the API documentation can be found atwd-vectordb.wmcloud.org/docs.
The Wikidata MCP (Model Context Protocol) provides a set of standardized tools that allow large language models (LLMs) to explore and query Wikidata programmatically. It is designed for agentic AI or AI workflows that need to search, inspect, and query Wikidata, without relying on hardcoded assumptions about its structure or content.
Use the Wikidata MCP when you want to integrate Wikidata directly into a GenAI model or into AI/ML workflows. The MCP provides a set of tools for exploring and accessing Wikidata, but it is limited to read-only use and does not include editing functionality.
The Wikidata MCP is implemented as an HTTP service available atwd-mcp.wmcloud.org. To use it, addhttps://wd-mcp.wmcloud.org/mcp/ as a connector in your AI client.
Wikidata dumps are complete exports of all the Entities in Wikidata:https://dumps.wikimedia.org
Use a dump when your result set is likely to be very large. You'll also find a dump important when setting up your own query service.
Don't use a dump if you need current data: the dumps take a very long time to export and even longer to sync to your own query service. Dumps are also unsuitable when you have significant limits on your available bandwidth, storage space and/or computing power.
If the records you need to traverse are many, or if your result set is likely to be very large, it's time to consider working with a database dump: (link to the latest complete dump).
You'll find detailed documentation about all Wikimedia dumpson the "Data dumps" page on Meta and about Wikidata dumps in particular on thedatabase download page.
It's no small task to procure a Wikidata dump and implement the above tools for working with it, but you can take a further step. If you have the capacity and resources to do so, you can host your own instance of the Wikidata Query Service and query it as much as you like, out of contention with any others.
To set up your own query service, followthese instructions from the query service team, which include procuring your own local copy of the data. You may also find useful information in Adam Shorland'sblog post on the topic.