Artist Profile By Name Resolver

Send an artist, producer, or songwriter name, even a messy or common one, and get one row back. A confident match returns a Wikidata QID carrying that entity's MusicBrainz, ISNI, IPI, Spotify, Discogs, and Apple Music IDs (each copied from Wikidata or left null, never invented), a match confidence computed by the formula published below, the full scored candidate list, and cited enrichment (aliases, years active, genres, roles) that is never charged. An ambiguous name returns a ranked shortlist instead of a guess; a name with no music entity behind it returns an explicit no-match. It is built for music researchers, catalog-cleanup teams, and AI agents that need a name-to-profile lookup before deeper catalog or rights work.

What Artist Profile By Name Resolver does

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. IPI is null 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. The run 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. A three-row demo dataset, generated on 2026-07-10 from real runs of this actor, 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 resolver 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 field is copied from the selected entity's own Wikidata statements or left null.

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 run that passes input validation, including no-match and upstream-failure runs. This is a request fee.
profile-resolved	$0.15	A confident single match with at least one verified identifier on the selected entity.
candidate-shortlist	$0.18	An ambiguous name that yields a ranked candidate list rather than one answer.
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-tier callers, and runs with no charge headroom left.
authoritative-profile-resolved	$0.40	Never, in this version. It is listed now because Apify requires 14 days' notice before a new 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 shortlist and bills candidate-shortlist instead of asserting a single profile.

Trying it with no PPE event. The default example in the Input tab ({ "name": "Gigamesh", "dryRun": true }) runs a real, bounded Wikidata lookup and charges no PPE event at all, not even the request fee, though ordinary Apify platform compute, storage, and egress usage still applies. dryRun only runs that exact sample; any other input with dryRun: true is rejected before any charge, lookup, or state read, and every other input runs the normal billed path described 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 PPE event. Valid ONLY for the exact public Store preview sample (name: "Gigamesh", no hints, maxCandidates: 5, includeSources: true); any other input with dryRun: true is rejected before any charge, lookup, or state read. The preview row still comes from a real, bounded, keyless Wikidata lookup and lands in your dataset and OUTPUT, so ordinary Apify platform usage (compute, storage, egress) 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. A field with no allowlisted source is null.
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. Many working songwriters have no Wikidata entity at all. When there is no entity, 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 null. IPI (P1828) is sparse in Wikidata even for household names, so it is returned when present and null 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? The top candidates scored within the tie band, so the resolver returned them ranked instead of picking one and risking the wrong namesake.

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. Run the default example input (dryRun: true on the exact "Gigamesh" sample): a real, bounded Wikidata lookup with no PPE event charged, though ordinary Apify platform usage still applies. dryRun is not a general no-charge mode: any other input with dryRun: true is rejected, and every other input runs the normal billed path.

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

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