Artist Profile By Name Resolver

Enter an artist or writer name, even a messy or ambiguous one, and get back a resolved identity record: a verified-or-null identifier bundle from Wikidata, a computed match confidence whose formula is published below, a ranked candidate list for common names, and cited enrichment (aliases, years active, genres, roles) as uncharged extras. It is built for music researchers, catalog-cleanup teams, and AI agents that need a normalized 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, published formula, and returns the one it can defend or an honest ranked shortlist when the name is genuinely ambiguous. 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 the join keys an agent actually chains on: 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 happens to carry it. Identifier fields are arrays, because a real entity can carry several valid IDs of one kind, and rank-ordered with the preferred value first.

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 surfaces the producer as the confident answer, with its MusicBrainz, Spotify, Discogs, Apple Music, and ISNI identifiers attached.

Ambiguous name, honest 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 match, honest no-match. Input { "name": "David Johnston" } returns outcome: no_match with ranked same-name candidates, each marked "no music gate", and an honestly 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 by the current production build, is public and needs no Apify account:

Demo dataset: three rows, JSON

One row per sold result event:

• 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 his 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: searching Gigamesh returns the music producer ranked third, below a 3D-mesh software framework and a Barcelona bookstore. Searching David Johnston returns ten same-name entities, none of them a music artist. The deterministic scorer and the music gate are the difference between that pile 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, the R&B singer, and Q115390006, a contemporary Christian artist); the single-answer reply collapses the two 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) sits on his public Wikidata record.
• This resolver on the same input, row 3 of the demo dataset: outcome: shortlist. Both Chris Browns score 1.0 inside the tie band, so no single profile is asserted and no identifier lands on the wrong namesake. 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. There is a flat request fee on every validated run, and result events that bill only when they are produced. A no-match or an upstream failure pays the request fee only.

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.20	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, served on the no-model path (for example a free-tier caller).

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 returns the profile and bills nothing beyond the request fee.

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 over the Wikidata data, not a model assertion. It is computed as a weighted sum and 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 all of 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. The threshold is 0.60 and the tie band is 0.10. A leader is decisive only when its score is at least 0.60 and it clears the runner-up by at least 0.10. Precedence, refusal 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, then the identifier floor. This ordering is why an ambiguous name returns a shortlist instead of a confident guess.

Input

• name (string, required): the artist or writer 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. The output row lists the full scored candidate pool. It never changes scoring or the tie test.
• 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 is still written to your dataset and OUTPUT from a genuine, bounded, free, keyless Wikidata lookup, so ordinary Apify platform compute, storage, and egress usage still applies.

Output

One row per lookup. You can download the dataset in JSON, HTML, CSV, or Excel. Each field is provenance-typed with value, source_type (wikidata or synthesized), source_urls, as_of, and confidence.

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. Each Wikidata-sourced or null, never model-filled, arrays 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.

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. The highest-value ambiguous queries are also the ones most likely to return an empty identifier bundle, and the ranked candidate list carries the value there.
• IPI is a rare bonus, not a headline. 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 lookup resolves who an entity is and its stable join keys. It does not return per-track ownership shares. It composes with rights and catalog products that do.
• Enrichment is discovery-grade. 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

The join keys are made to be chained:

• 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 name was ambiguous and the top candidates scored within the tie band, so the resolver returned ranked candidates rather than assert a single wrong one.

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 default example input (dryRun: true on the exact "Gigamesh" sample). It charges no PPE event at all and runs a real, bounded Wikidata lookup, though ordinary Apify platform compute, storage, and egress 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.