Wikidata SPARQL Scraper - Live Queries, $0.50/1k Rows

Wikidata SPARQL Scraper

Why use this scraper

Wikidata is the largest free, structured knowledge graph on the web: over 100 million items covering people, places, organizations, chemical compounds, scientific papers, awards, and the relationships between all of them. The catch is that getting data out of it means writing and running SPARQL, a query language most developers, analysts, and researchers have never touched and don't want to learn just to pull a list of countries and their capitals or a table of Nobel Prize winners.

Even once you have a working query, running it yourself means standing up an HTTP client, handling the Wikidata endpoint's rate limits and timeouts, parsing the SPARQL JSON results format (which nests every value in a type/value wrapper), and flattening that into something you can actually load into a spreadsheet or a database. This scraper does that last mile: paste any SPARQL query, get back a flat, ready-to-use dataset. No SPARQL client to install, no JSON wrangling, no local script to maintain.

Overview

You submit a SPARQL query (your own, or one of the examples below). The actor sends it to the official Wikidata Query Service, waits for the result set, and flattens every row into a plain JSON object: one key per variable in your SELECT, plus companion fields that tell you whether each value is a URI, a literal, or a blank node, and what language a literal is in. Results stream into an Apify dataset as they come back, capped by the maxItems you set. A query against Wikidata's public endpoint typically returns in a few seconds to under a minute, depending on how much of the graph it has to touch; the Wikidata service itself enforces a 60-second execution timeout per query, so anything heavier needs to be split into smaller queries with tighter LIMIT clauses.

Supported inputs

• Any valid SPARQL query (the only required field): standard SELECT queries with WHERE, FILTER, OPTIONAL, SERVICE wikibase:label, and LIMIT all work exactly as they would if you ran the query directly on query.wikidata.org.
• Pre-filled example query: if you leave the query field untouched, it runs a sovereign-states-and-capitals query so you can see the shape of the output before writing your own.
• Row cap (maxItems): an extra safety limit on top of whatever LIMIT you put in the query itself, so a query without its own limit can't return more rows than you intended to pay for.
• Debug logging: optional verbose logs if a query isn't behaving the way you expect.

Use cases

• Knowledge graph researchers pulling structured entity relationships (people born in a city, companies headquartered in a country, drugs that treat a condition) for academic work or graph-database seeding.
• Data journalists and analysts building one-off datasets, like every head of state since 1900 or every chemical element with its discovery year, without learning a new query language from scratch.
• Product and growth teams doing entity enrichment, matching a list of company names or people to their Wikidata IDs, countries, industries, or founding dates.
• ML and NLP teams generating labeled training data from Wikidata's structured facts, such as entity-relationship pairs for knowledge-graph embedding models.
• Genealogy and reference-site builders who need bulk, structured facts (capitals, populations, flags, currencies) rather than free-text Wikipedia articles.

How it works

The actor is a thin, reliable bridge to the Wikidata Query Service: it posts your SPARQL query to the official public endpoint, reads back the standard SPARQL 1.1 JSON results format, and does the flattening work the format itself doesn't do for you. Every bound variable ?x in your query becomes four possible output fields: x (the value itself), x_type (uri, literal, or bnode), x_lang (the language tag, for literals that have one, like labels pulled via SERVICE wikibase:label), and x_datatype (the XSD datatype URI, for typed literals like dates or numbers). That means a query returning ?country, ?countryLabel, ?capital, and ?capitalLabel comes back as flat rows with up to 16 fields, no nested objects to unpack. The actor identifies itself to the Wikidata endpoint with a descriptive user agent, as the Wikidata terms of use ask of automated clients, so queries aren't mistaken for abusive traffic.

Input configuration

Countries and their capitals (the default example):

{
  "query": "SELECT ?country ?countryLabel ?capital ?capitalLabel WHERE {\n  ?country wdt:P31 wd:Q3624078.\n  ?country wdt:P36 ?capital.\n  SERVICE wikibase:label { bd:serviceParam wikibase:language \"en\". }\n}\nLIMIT 50",
  "maxItems": 50
}

Nobel Prize winners with year awarded:

{
  "query": "SELECT ?person ?personLabel ?prizeLabel ?year WHERE {\n  ?person wdt:P166 ?prize .\n  ?prize wdt:P31/wdt:P279* wd:Q7191 .\n  OPTIONAL { ?person p:P166 ?stmt . ?stmt ps:P166 ?prize . ?stmt pq:P585 ?date . BIND(YEAR(?date) AS ?year) }\n  SERVICE wikibase:label { bd:serviceParam wikibase:language \"en\". }\n}\nLIMIT 1000",
  "maxItems": 1000
}

Chemical elements with atomic number and discovery year:

{
  "query": "SELECT ?element ?elementLabel ?atomicNumber ?discovered WHERE {\n  ?element wdt:P31 wd:Q11344.\n  ?element wdt:P1086 ?atomicNumber.\n  OPTIONAL { ?element wdt:P575 ?discovered. }\n  SERVICE wikibase:label { bd:serviceParam wikibase:language \"en\". }\n}\nORDER BY ?atomicNumber",
  "maxItems": 150
}

Output sample

Real rows from the countries-and-capitals query above:

[
  {
    "country": "http://www.wikidata.org/entity/Q16",
    "country_type": "uri",
    "capital": "http://www.wikidata.org/entity/Q1930",
    "capital_type": "uri",
    "countryLabel": "Canada",
    "countryLabel_type": "literal",
    "countryLabel_lang": "en",
    "capitalLabel": "Ottawa",
    "capitalLabel_type": "literal",
    "capitalLabel_lang": "en"
  },
  {
    "country": "http://www.wikidata.org/entity/Q17",
    "country_type": "uri",
    "capital": "http://www.wikidata.org/entity/Q1490",
    "capital_type": "uri",
    "countryLabel": "Japan",
    "countryLabel_type": "literal",
    "countryLabel_lang": "en",
    "capitalLabel": "Tokyo",
    "capitalLabel_type": "literal",
    "capitalLabel_lang": "en"
  }
]

Key output fields

Field (pattern)	Type	Description
<variable>	string	The bound value for that SPARQL variable: a Wikidata entity URI, a literal string, or a number, depending on the query.
<variable>_type	string	uri, literal, or bnode, telling you how to interpret the value above.
<variable>_lang	string	Language tag (e.g. en, pt), present only on literals that carry one, such as labels.
<variable>_datatype	string	XSD datatype URI, present on typed literals like dates (xsd:dateTime) or numbers (xsd:decimal).

The exact set of fields depends entirely on which variables your SELECT clause asks for, since the actor flattens whatever Wikidata returns.

Pricing

Pay-per-event pricing, billed only on successful rows:

Event	Price
Actor start	$0.00005 (one-time per run, scaled by memory)
Row scraped	$0.0005

That works out to $0.50 per 1,000 rows. A query that returns an error or an empty result set is not charged.

What makes this richer than the competition

Most Wikidata actors on the Apify Store wrap a single fixed use case (an entity lookup, a company finder) and charge accordingly: fortuitous_pirate/wikidata-scraper prices at $10 per 1,000 rows, twenty times this actor's rate, for a narrower, pre-built query surface. gochujang/wikidata-sparql-query offers raw SPARQL access similar to this actor but is scoped to companies, people, geography, and science categories rather than accepting any valid query against the full graph. This actor accepts any SPARQL query against the complete Wikidata graph, at $0.50 per 1,000 rows, with no restriction on entity type or query shape, so it fits research use cases a fixed-template actor can't: genealogy charts, scientific taxonomies, award histories, or anything else modelable in Wikidata's schema.

Notes & limitations

• The Wikidata Query Service enforces a hard 60-second execution timeout per query. A query that touches too much of the graph (missing LIMIT, overly broad FILTER) will time out rather than return partial results; narrow the query or raise the LIMIT incrementally.
• This actor does not validate or rewrite your SPARQL. A malformed query returns whatever error the Wikidata endpoint sends back, surfaced as-is.
• maxItems caps rows after the query runs; it does not make an unbounded query faster. Always include your own LIMIT for predictable run times.
• Values come back exactly as Wikidata stores them: dates as ISO strings with datatype URIs, entity references as full wikidata.org/entity/Qxxx URIs rather than human-readable names (use SERVICE wikibase:label in your query to also pull the label).
• Blank nodes (bnode) appear occasionally in complex queries with anonymous intermediate nodes; they have no stable ID to join on across runs.

FAQ

Do I need to know SPARQL to use this? You need a working SPARQL query, yes. The three examples above cover common patterns (type + property lookup, award history, element/taxonomy lookup) you can copy and adapt by swapping the Wikidata property and entity IDs for your topic.

How do I find the right Wikidata property and entity IDs for my topic? Search for your entity or property on wikidata.org (e.g. search "country" to find Q6256, or "capital of" to find P36), then plug the Q and P codes into a query modeled on the examples here.

Can I run the same query on a schedule to track changes? Yes. Wikidata is edited continuously, so scheduling this actor daily or weekly against the same query is a reasonable way to track additions (new entries matching your WHERE clause) over time.

What happens if my query times out? You get Wikidata's timeout error back, and because errored rows aren't charged, a timed-out run costs only the one-time actor start event. Narrow the query and retry.

Does this work for languages other than English? Yes. Swap the "en" language tag inside SERVICE wikibase:label for any language code Wikidata supports (pt, es, fr, de, and dozens more) to get labels in that language instead.

Can I query for a single entity instead of a list? Yes, bind the SPARQL variable to a specific wd:Qxxx entity ID instead of a type, and the query returns just that entity's matching facts.

For AI Agents & LLM Apps

This actor is callable directly from AI agents and LLM applications, either through the Apify MCP server or the REST API.

Via MCP (mcp.apify.com): add the Apify MCP server to your agent's tool config and call this actor by its ID, gio21/wikidata-sparql-scraper, passing query and maxItems as arguments. The agent gets back structured rows it can reason over directly, no SPARQL client needed on the agent's side.

Via API (run-sync-get-dataset-items):

curl "https://api.apify.com/v2/acts/gio21~wikidata-sparql-scraper/run-sync-get-dataset-items?token=<YOUR_TOKEN>" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "query": "SELECT ?country ?countryLabel ?capital ?capitalLabel WHERE { ?country wdt:P31 wd:Q3624078. ?country wdt:P36 ?capital. SERVICE wikibase:label { bd:serviceParam wikibase:language \"en\". } } LIMIT 50",
    "maxItems": 50
  }'

This call blocks until the run finishes and returns the dataset items directly in the response, which fits synchronous agent tool calls well.

Disclaimer

Wikidata and the Wikidata logo are trademarks of the Wikimedia Foundation. This actor is an independent tool that queries Wikidata's public SPARQL endpoint and is not affiliated with, endorsed by, or sponsored by the Wikimedia Foundation.

SEO Keywords

wikidata scraper, sparql query tool, wikidata api, sparql to json, wikidata query service, knowledge graph scraper, wikidata dataset