Artist Lookup by Name: Spotify, MusicBrainz & ISNI IDs

Send a music artist, producer, or songwriter name, even a messy or common one, and get one row back with that artist's join keys: the Spotify artist ID, MusicBrainz ID, ISNI, Discogs and Apple Music IDs, each copied from the matching Wikidata record or left empty, never invented. The row also carries a match confidence from the formula published below, plus the ranked candidates behind it.

An ambiguous name returns a ranked shortlist instead of a guess; a name with no music entity behind it returns an explicit no-match. On a paid plan the row adds cited enrichment (aliases, years active, genres, roles), which is never charged. This Actor is for music data and research teams, and for AI agents that need to settle which artist a name refers to before any deeper catalog or rights work.

What you send:

{ "name": "Gigamesh" }

What comes back: one row with outcome: resolved, the music producer Q5560170 as the best match, and match_confidence 1.0. That row carries the entity's own MusicBrainz ID, ISNI, Spotify artist ID, Discogs artist ID, and Apple Music artist ID, each copied from its Wikidata statements.

Open real rows before you spend anything: demo dataset, three rows, JSON.

What Artist Lookup by Name does

This Actor was listed as "Artist Profile By Name Resolver" until 2026-09-10: same URL, same Actor id.

You give it a name. It searches Wikidata (CC0, keyless), scores every candidate with a deterministic formula, and labels the row with one of five outcomes:

• resolved: one entity clears both the threshold and the tie band, and the ranking model agrees with it.
• shortlist: the name is genuinely ambiguous, so you get the ranked candidates instead of a guess.
• identity_core_only: a decisive Wikidata match served without the ranking model, so the QID and identifiers come back with no synthesized enrichment.
• no_match: nothing survives the music gate, the threshold, and the tie band together.
• error_upstream: the Wikidata lookup itself failed, so no profile was produced.

Every external identifier it returns comes from the selected entity's own Wikidata statements. The model never fills an identifier, so an ID is never borrowed from a same-name lookalike.

The identifier bundle covers these join keys: MusicBrainz ID (P434), Wikidata QID, ISNI (P213), Spotify artist IDs (P1902), Discogs artist IDs (P1953), Apple Music artist IDs (P2850), and IPI (P1828) when Wikidata carries it. Every identifier field except qid is an array ordered by Wikidata statement rank, preferred value first, because one entity can legitimately hold several valid IDs of the same kind.

Worked examples (real input, real output)

Household name, high-confidence single match. Input { "name": "Miley Cyrus" } resolves to Q4235 with match_confidence 1.0 and a near-full bundle: MusicBrainz ID 7e9bd05a-117f-4cce-87bc-e011527a8b18, three ISNIs, two Spotify artist IDs (5YGY8feqx7naU7z4HrwZM6, 14scxEoUN7Dcx1m4EQ7oHe), a Discogs ID, and an Apple Music ID. The IPI array is empty here, which is normal even for household names.

Niche name that raw search buries. Input { "name": "Gigamesh" } resolves to the music producer Q5560170. A raw Wikidata search ranks that entity third, below a 3D-mesh software framework and a Barcelona bookstore. The music-class gate demotes the non-music entities and returns the producer as the confident answer, with its MusicBrainz, Spotify, Discogs, Apple Music, and ISNI identifiers attached.

Ambiguous name, ranked shortlist instead of a guess. Input { "name": "Chris Brown" } returns outcome: shortlist. Two music-class Chris Browns (Q155700, the American R&B singer, and Q115390006, a contemporary Christian artist) both score 1.0 inside the tie band, so no single profile is asserted and no identifier bundle is attached to either. That demo run, on a paid plan, bills candidate-shortlist.

Name with no music entity behind it. Input { "name": "David Johnston" } returns outcome: no_match with ranked same-name candidates, each marked "no music gate", and an empty identifier bundle, because no David Johnston in Wikidata carries a music-class statement or a music identifier. This run is not charged a result event. You pay the request fee only.

A public demo dataset you can open right now

The examples above are not mockups. The three-row demo dataset behind them holds lab-generated examples of paid-path output: on 2026-07-10 the deployed build ran these three names with the paid path switched on, against live Wikidata and the live ranking service, and the rows are what came back. It is public and needs no Apify account:

Demo dataset: three rows, JSON

One row per lookup:

• Row 1, { "name": "Miley Cyrus" }: outcome: resolved, confidence 1.0, the full identifier bundle shown above, cited enrichment fields. Bills profile-resolved.
• Row 2, { "name": "Gigamesh" }: outcome: resolved to the producer Q5560170, with that entity's MusicBrainz, ISNI, Spotify, Discogs, and Apple Music IDs attached. Bills profile-resolved.
• Row 3, { "name": "Chris Brown" }: outcome: shortlist, both music-class Chris Browns ranked at confidence 1.0 inside the tie band, no identifier bundle attached to either. Bills candidate-shortlist.

The same names through the free baselines, captured 2026-07-10

Raw Wikidata search, the free directory this Actor reads: Gigamesh puts the music producer third, behind the software framework and the bookstore. David Johnston returns ten same-name entities, none of them a music artist. The deterministic scorer and the music gate are the difference between those results and the rows above.

A direct structured LLM web-search call (Perplexity sonar, asked for {"name", "spotify_artist_id", "musicbrainz_id"} as JSON only, both calls made 2026-07-10):

• Asked for Chris Brown: one artist back, no ambiguity signal, carrying the R&B singer's correct Spotify ID and a MusicBrainz ID that does not exist. The returned MBID e319600a-9c0a-4b7b-9c0a-4b7b9c0a4b7b returns 404 on musicbrainz.org and matches neither same-name artist's registered MBID. Wikidata lists two music-class Chris Browns (Q155700 and Q115390006); the single-answer reply collapses them into one.
• Asked for the contemporary Christian Chris Brown specifically: "N/A" for both IDs, plus explanatory prose appended to a reply requested as JSON only. That artist's Spotify ID (03NN8FAKofZU6phsfHLKPw) is on their public Wikidata record.
• This Actor on the same input, row 3 of the demo dataset: outcome: shortlist, both Chris Browns at 1.0 inside the tie band, no identifier attached to either. An invented ID has no path into the output: every identifier value is copied from the selected entity's own Wikidata statements.

Pricing

Billing is pay-per-event: a flat request fee on every validated run, and result events only when their data is produced. A no-match or an upstream failure pays the request fee and nothing else.

Event	Price	When it bills
actor-start	$0.02	Every validated run except the dry-run sample, including no-match and upstream-failure runs. This is a request fee.
profile-resolved	$0.15	A confident single match on a paid plan: the ranking model agrees with the top-scoring entity, and that entity carries at least one verified identifier.
candidate-shortlist	$0.18	An ambiguous name on a paid plan: at least two music-class candidates clear the 0.60 confidence threshold, and no single profile is asserted.
identity-core	$0.05	A confident Wikidata-only match with at least two verified identifiers, on a run that never calls the ranking model: free-plan callers, and runs with no charge headroom left.
authoritative-profile-resolved	$0.40	Never, in this version. It is listed now because Apify's monetization rules require 14 days' notice before a new paid event can start billing; a future cross-source reconciliation upgrade would use it.

Enrichment fields (aliases, years active, genres, roles, notable works, recent activity) are never charged. At most one result event bills per run. A confident match that carries zero external identifiers still returns the profile and never bills profile-resolved; when it is also the only music-class candidate above the threshold, the run bills nothing beyond the request fee.

A lookup runs the ranking model at most once. If that one pass cannot settle which candidate the name refers to, the run returns the ranked candidates instead of asserting a single profile, and bills candidate-shortlist when at least two music-class candidates clear the 0.60 threshold.

What the first run costs. The Input tab opens with name filled in as Gigamesh and Dry run off, so the first Start runs the normal billed path. For that sample it bills the $0.02 request fee plus identity-core at $0.05 on a free plan. On a paid plan it bills $0.02 plus profile-resolved at $0.15 when the ranking model agrees with the match, as it did for the Gigamesh demo row; when the model does not agree, the row still comes back and only the request fee bills, because Gigamesh has just one music-class candidate. A free-plan run returns the Wikidata identity core, the QID and its identifiers, without the synthesized enrichment fields; rows 1 and 2 of the demo dataset above show the enriched paid-path row in full. A run started with no input at all uses the sample input { "name": "Gigamesh" } and is billed like any other run.

Trying it with no pay-per-event charge. Switch Dry run on (or send dryRun: true) for that exact sample: name Gigamesh, no hints, maxCandidates 5, includeSources true. That run does a real, bounded Wikidata lookup, charges no pay-per-event fee at all, not even the request fee, and never calls the ranking model. Ordinary Apify platform compute, storage, and egress still apply. Any other input with dryRun: true is rejected before any charge, lookup, or state read, so every other input runs the normal billed path above.

The confidence formula, published

match_confidence is a deterministic score computed from the Wikidata record, not a model assertion. It is a weighted sum, rounded to four decimals.

• With hints: S = 0.55 * N + 0.25 * M + 0.20 * H
• Without hints: S = (0.55 * N + 0.25 * M) / 0.80, which renormalizes the same two terms to the 0 to 1 range.

N, name match (weight 0.55) is the highest tier reached across the candidate's labels and aliases after Unicode normalization, casefolding, and diacritic stripping: 1.00 for an exact match, 0.90 when the tokens match in any order, 0.75 when one token set contains the other (middle-name cases), a bounded value in the 0.51 to just-under-0.60 band for a close typo, otherwise 0.

M, music class (weight 0.25) is binary: 1 when the candidate has a music occupation or musical-group class in a frozen, version-pinned set, or carries any of the MusicBrainz, Spotify, Discogs, or Apple Music identifiers, otherwise 0.

H, hint agreement (weight 0.20) applies only when you supply hints. Each hint scores 1.0 when it agrees, 0.5 when the candidate is silent on it, and 0.0 when it contradicts. H is the mean over the supplied hints.

Decision rules. A leader is decisive only when it scores at least 0.60 (the threshold) and clears the runner-up by at least 0.10 (the tie band). The rules apply in this order, refusals first: the music gate, then the tie rule (a tied top pair never becomes a single charged profile, even when the model agrees), then the threshold, then a hint veto, then model agreement, and last the identifier floor. That last one decides only whether the run bills: a winner carrying no verified external identifier is still returned to you; it just does not bill profile-resolved. This ordering is why an ambiguous name returns a shortlist instead of a confident guess.

Input

• name (string, required): the artist, producer, or songwriter name.
• hints (object, optional): country, genre, role, knownWork, externalUrl. Hints sharpen the score; they are never required.
• maxCandidates (integer, optional, default 5, max 10): how many candidates are sent to the ranking model. It never changes scoring or the tie test, and the output row still lists the full scored candidate pool.
• includeSources (boolean, optional, default true): include evidence URLs.
• dryRun (boolean, optional, default false): charges no pay-per-event fee. Valid only for the exact prefilled sample (name: "Gigamesh", no hints, maxCandidates: 5, includeSources: true); any other input with dryRun: true is rejected before any charge, lookup, or state read. That row still comes from a real, bounded, keyless Wikidata lookup and lands in your dataset, so ordinary Apify platform usage still applies.

Output

One row per lookup. You can download the dataset in JSON, HTML, CSV, or Excel. The six enrichment fields are provenance objects rather than bare values: value, source_type (always synthesized), source_urls, as_of, and confidence. Every other field, identifiers included, is a plain value or array.

Field	Meaning
query_name	The name you sent, echoed.
outcome	resolved, shortlist, identity_core_only, no_match, or error_upstream.
best_match_name, match_confidence, ambiguity_level	The selected entity, its computed score, and how ambiguous the name was.
identifiers	qid, mbid, isni, ipi, spotify_artist_ids, discogs_artist_ids, apple_music_artist_ids. Every value comes from Wikidata and none is ever model-filled; qid is null and the arrays are empty when nothing is known. Arrays are ordered by statement rank.
aliases, years_active, genres, roles, notable_works, recent_activity	Synthesized, cited, uncharged enrichment. Each is an object whose value is null when no allowlisted source supports it.
ranked_candidates[]	name, qid, confidence, evidence_urls, and a short reason per candidate.
warnings[]	Budget, cache, and policy-drop notices.
charged_event	Which result event billed this run, or null when nothing beyond the request fee billed.
dry_run	True only on the sample-locked dryRun preview.

Limitations

• Wikidata coverage is thinner for the long tail. An act with no Wikidata entity has nothing to match, so the run returns a no-match and is not charged a result event. When an entity exists but carries no external identifiers, you still get the profile and the scored candidate list, and no profile-resolved event fires.
• IPI is usually empty. IPI (P1828) is sparse in Wikidata even for household names: the Miley Cyrus demo row carries none. You get an IPI when Wikidata carries one, and an empty array otherwise.
• Identity resolution, not a rights registry. This returns who an entity is and its stable join keys, not per-track ownership shares. For those, chain into the MLC resolver linked below.
• Enrichment is cited, not authoritative. Aliases, years active, genres, and roles are synthesized with citations from a fixed allowlist of music press and public broadcasters. A fact with no allowlisted source is returned null rather than guessed.

Composes with

Once you know which artist you have:

• Spotify Catalog Resolver turns ISRCs, UPCs, ISWCs, or free-text queries into full Spotify catalog metadata. Resolve the artist here first, and you know whose catalog you are looking at.
• MLC Rights Resolver resolves ISRCs or MLC song codes into the writers, publishers, and ownership shares The MLC has on file. That is the per-track rights layer this identity lookup deliberately does not duplicate.

FAQ and support

Where do the identifiers come from? Only from the matched entity's Wikidata statements. Wikidata is CC0, so the join keys are reusable without attribution. MusicBrainz is never called.

Why did I get a shortlist instead of one answer? Either the top candidates scored within the tie band, or the ranking model would not commit to one of them. Either way this Actor returns them ranked rather than guessing which namesake you meant.

Why was I charged on a no-match? The $0.02 request fee applies to every validated run. Result events bill only when produced, so a no-match pays the request fee and nothing more.

Can I try it before paying? Yes, with the Dry run switch. Turn Dry run on for the exact Gigamesh sample (name: "Gigamesh", no hints, maxCandidates: 5, includeSources: true) and the run does a real, bounded Wikidata lookup, charges no pay-per-event fee, and never calls the ranking model. Ordinary Apify platform usage still applies. Left off, which is how the Input tab opens, that same sample runs the billed path: $0.02 plus identity-core on a free plan, and on a paid plan $0.02 plus profile-resolved when the ranking model agrees with the match, or the $0.02 alone when it does not. Any other input with dryRun: true is rejected, so it is not a general no-charge mode. To see the enriched paid-path row without running anything, open rows 1 and 2 of the demo dataset above.

Feedback and bug reports go to the Issues tab. Custom fields or a wider enrichment allowlist can be scoped on request.

SEO: artist lookup, artist name lookup, Spotify artist ID, MusicBrainz ID, ISNI lookup, music artist, artist profile, artist resolver, songwriter lookup, music metadata, MCP.