Wikidata:Wikibase GraphQL prototype

The Wikibase Reuse Team has recently built a prototype for a GraphQL API. We are currently collecting feedback about the introduction of a new type of API into the ecosystem. We have been talking to developers inside Wikimedia Deutschland and the Wikimedia Foundation to discuss its technical feasibility and future prospects. But, we also want to hear from the community – please tell us what you think about the potential of a GraphQL API.

If completed, it would provide an alternative to the Wikidata Query Service (WDQS) for accessing Wikidata’s data in certain simple ways. The WDQS would still be needed for complex queries, but for a few frequent use cases there would be an alternative for users without having to worry about timeouts. These planned options are outlined below.

The prototype’s functionality is currently limited to requesting labels of linked entities. This means you are able to request the label of statement properties and labels of entities used as statement values.

If we continue to build this API, the next planned features include:

• Bulk GET: Requesting data of multiple items (or any entities) at once
• Inverse look up: Finding items by statement property value pairs, e.g. instance of: house cat, occupation: railway worker

It’s also possible that there are even more uses for the API beyond these initial ones, but please give us feedback on if these first three options would be interesting for you.

• Phabricator parent ticket: T399452 🧬 Wikibase GraphQL Prototype

Try it out on patch demo:

• Example Data: Zeus (Q1), Hera (Q4)
• GraphQL client: Special:WikibaseGraphQLSandbox

Please note that the prototype is currently limited to querying Item and String statement values only.

Example query:

 {item(id: "Q4") {
   labels {
     en
     de
   }
   statements {
     property {
       id
       labels {
         en
         de
       }
     }
     value {
       ... on StringValue {
         content
       }
       ... on ItemValue {
         item: content {
           id
           labels {
             en
             de
           }
         }
       }
     }
   }
 }}

Give the prototype a try! There is a sandbox on the patchdemo and we’ve provided an example query above. Keep in mind that there are limited items imported to this test wiki and not all features are there yet.

Copy and paste the question guide below. Feel free to skip any questions if you don’t have anything to say and you’re welcome to also share any feedback which doesn’t fit perfectly to the questions. We’d like to hear your thoughts!

Please copy and paste below into Comments section

• How do you feel about the introduction of a new technology, GraphQL?

• What do you think of the planned features? Are there any specific functionalities you’d like to see built out into this?

• Would you need any specific support to try it out?

• Is there anything else you’d like to share with us?

•  Support Thanks for doing this! The bulk request is the biggest thing I would like to see (if it was supported somehow on the REST API that might be fine too). Very often I want to fetch certain labels and property values on a possibly large number of items, which it sounds like this GraphQL API would be ideal for. I'll have to try it out. ArthurPSmith (talk) 19:54, 25 August 2025 (UTC)[reply]
• It looks quite interesting. It would be nice to see a bit the result of the discussions stemming from https://phabricator.wikimedia.org/T396983 to understand better the need for yet another interface, though it could fill a few gaps. The reverse lookup feature would be a must for basic usefulness in my case. In general, I believe the usefulness would come from somewhere between the WDQS and the REST API, if there is actually human power to maintain so many interfaces. In that way, it would be great to know what it can do for (very) large Wikibases that currently WDQS struggles to do and which kind of gaps it could fill. TiagoLubiana^{🌴T🦋C🐬} 14:27, 27 August 2025 (UTC)[reply]

  Hi Tiago! You should now be able to see a summary of the investigation on the ticket you linked. Regarding your other question, it remains to be seen, but we're going to actively work together with the new Wikidata platform team on that problem. Ifrahkhanyaree WMDE (talk) 14:06, 2 September 2025 (UTC)[reply]

• I see that it grabs the labels for the item-value. Does this mean it supports recursion? For instance will it be possible to write a query that asks for items for cities and then have it recurse into the P131 values a couple of layers with labels and perhaps some other property like the area of the county?

Pagination support might be useful. And support for basic filtering of results based on value would be very useful to keep network I/O down. It should be sufficient to support filtering on exact matches and exact non-matches probably. Infrastruktur (talk) 16:29, 27 August 2025 (UTC)[reply]

Thinking about it, it might be a good idea to limit recursion to say one layer, to discourage people using it for something that they would be better of using SPARQL for, as it will likely have better scaling properties. Infrastruktur (talk) 11:00, 1 September 2025 (UTC)[reply]

Hi Infrastruktur, thank you for the helpful feedback!

• The prototype does not support recursion, but if there is a need from more people for this then I could imagine us adding the functionality in the future
• When we build out the official version 1, we will definitely add filtering and pagination

Ifrahkhanyaree WMDE (talk) 14:13, 2 September 2025 (UTC)[reply]

•  Support This looks interesting to me as well! It would be useful for my Citation.js library to be able to fetch bibliographic items and labels of the associated authors, journals, editors, publishers, publisher addresses, etc. in a single request. --Lagewi (talk) 10:14, 29 August 2025 (UTC)[reply]