The Wikidata API resolves a name into a stable entity id. You hand it a string — "OpenAI" — and it returns the candidate Wikidata entities, each with its Q-id (Q21708200), label, short description, canonical concept URI and page URL. That Q-id is the join key: the thing that turns a messy free-text name into an identifier a dataset, a knowledge graph or an LLM pipeline can rely on.
It runs Wikidata's entity search, keyless and in any language you set, and returns the ranked candidates with the matched text and match_type so you can see whether a label or an alias hit. This is resolution, not extraction — it maps a name to its Q-id; it does not dump the entity's full set of statements and properties. Each search is fetched over our TLS tier through a rotating residential exit, no browser. For records that need entity ids attached, it pairs naturally with the clinical trials API and its sponsor names.
$0.0003 per delivered entity, up to 50 entitys per run. Nothing delivered means nothing charged.
You post a query and, optionally, a lang; the collector calls Wikidata's search endpoint and returns the ranked candidate entities as rows. No browser, no key, and every run returns inline.
id (the Q-number), label and description — enough to disambiguate "Apple" the company from "apple" the fruit at a glance.concept_uri. Alongside the Q-id, the canonical entity URI is the value you store to link records across datasets unambiguously.lang and labels and descriptions come back in that language, so resolving "Leonardo da Vinci" in Italian works as cleanly as English.Because it returns candidates, the row you want is usually the top-ranked one — but the match_type field lets you confirm it matched on a label rather than a loose alias before you commit the id.
query is the only required input — the name or term to resolve; lang sets the language of labels and descriptions (default English) and max_results caps the run at up to 50 candidate entities.
Each candidate is one row: the Wikidata id (Q-number), label, description, canonical concept_uri, page url, and the matched text with its match_type so you can judge the match.
$0.0003 per delivered entity ($0.30 per 1,000). Nothing delivered means nothing charged, and the $2 monthly free credit covers roughly 6,666 entitys here. Volume tiers take up to 30% off.
$0.0003 per delivered entity — 30 cents per 1,000 candidate rows. Resolving a column of ten thousand names, even pulling several candidates each to disambiguate, lands in single-digit dollars.
A query that matches no entity returns no rows and is not billed, so the unresolvable names in a dirty list cost you nothing.
Wikidata publishes its own wbsearchentities action API and the powerful Wikidata Query Service (SPARQL), both free. For a few lookups, call them directly. Two things push people off the raw endpoints at scale: the action API's response is verbose and its rate limits bite when you fire thousands of resolutions in a loop, and SPARQL is a different skill and a shared service that returns 429s under heavy programmatic use.
This collector wraps the search action into a clean, typed row and runs it through rotating exits, so a bulk name-resolution job is a steady stream of tidy rows rather than a hand-tuned backoff loop against a shared endpoint. It is not a SPARQL replacement — if you need to query relationships between entities, SPARQL is still the right tool.
Calling wbsearchentities yourself is simple until you scale it: you add retry and backoff for the rate limit, parse a verbose response down to the fields you actually use, and rank candidates consistently across languages. It is a small library that quietly grows.
The collector is that library as a priced endpoint — a flat row per candidate, failures never billed, one key shared across your pipeline. If you only need dependable network exits under your own resolver, that is what our residential proxies provide.
Resolve a column of free-text names — companies, people, places — to Q-ids so records from different sources join on a stable identifier instead of on spelling.
Turn extracted mentions into canonical Wikidata ids to ground them, deduplicate references and attach a concept_uri the rest of your stack can follow.
Pull several candidates per query and use label, description and match_type to pick the right entity — the company, not the album of the same name.
This is entity resolution: it maps a name to candidate Q-ids and their labels, descriptions and URIs. It does not return an entity's statements — its properties, relationships, sitelinks or values. Once you have the Q-id, fetching those is a separate step (Wikidata's entity-data endpoints or SPARQL), and this collector deliberately does not try to be that.
Rankings and descriptions are Wikidata's own, community-maintained and occasionally sparse for obscure entities; the top candidate is usually right but not guaranteed, which is why match_type is in every row. One run returns up to 50 candidates. Wikidata content is CC0, which makes it unusually free to reuse.
Wikidata's own API is free and keyless. Here light use falls under the $2-a-month free allowance — roughly 6,600 entities at $0.0003 each — then pay-as-you-go with no subscription.
No. Wikidata's search endpoint is keyless, and here you authenticate only with your QuantumProxies key. There is no Wikidata account, token or registration involved.
Yes — that is much of the point. Bulk resolution against Wikidata's endpoint hits rate limits quickly from one IP; here requests run through rotating residential exits and your throughput is governed by your plan's rate limit rather than by a shared endpoint's backoff.
Just the resolution: the Q-id, label, description, concept URI and match metadata. To read an entity's statements and relationships, use the Q-id with Wikidata's entity-data endpoints or SPARQL — this collector finds the id, it does not dump the full entity.