Identity
Look a recording up by a Spotify or Deezer link, an ISRC, a MusicBrainz id, or a Log ID: the links Fluncle found, and where he looked and found nothing.
Fluncle knows, for tens of thousands of recordings, that this recording is this Spotify link is this MusicBrainz id is this ISRC. This is how you ask.
Ask on the web at /identity, or from a machine through the track endpoint. Both read the same answer, so the page and the API tell you the same thing about a recording. They present it differently on purpose: the page is a receipt, one row per thing Fluncle covers, while the API answers every platform explicitly so a machine caller never has to infer a gap from a missing field. One field also differs in substance, and only one: Apple Music, for a licence reason spelled out below.
The keys
| Key | Looks like | Where it comes from |
|---|---|---|
| ISRC | GBXXX0000000 | The recording's own international standard code. Hyphens and spaces are fine; they are stripped. |
| MusicBrainz recording id | a UUID | The recording's id at musicbrainz.org. |
| Log ID | 004.7.2I | The coordinate Fluncle stamps on a recording he has certified. See Log ID. |
| Spotify link | open.spotify.com/track/… | Straight off a share sheet. The spotify:track: URI and the bare 22-character id work too. |
| Deezer link | deezer.com/track/… | Straight off a share sheet. The bare numeric id works too. |
One key, one page: https://www.fluncle.com/identity/<key>.
A pasted link needs no tidying. Fluncle reads past a locale in the path (/nl/track/…, /intl-de/track/…) and a tracking tail (?si=…, ?utm_source=…), so the same track pasted three different ways lands on one address rather than three. Beatport is the one platform that is a destination only, never a key. Fluncle keeps a Beatport URL and no Beatport id, and matching a URL by its tail means reading every row in the archive to answer one question. He would rather leave that key out than answer it slowly.
An answer is a list, not a row. An ISRC is not unique in this archive, and neither is a MusicBrainz id across the paths a recording can arrive by. So a lookup brings back every recording Fluncle has on file under the key, each marked with how it stands to the others: the only answer, one of several he has not ruled between, or a duplicate of another recording here. Picking a winner quietly is exactly what this surface exists not to do.
What is covered
Eight rows on the answer page: two identifiers, ISRC and MusicBrainz, and six links out, Spotify, Apple Music, Deezer, Discogs, Beatport, and YouTube. Apple Music is page-only, for the licence reason below.
Deezer is covered, but thinly. Fluncle keeps a Deezer link only when another look at that recording already brought one back and it matches the recording he holds. Everything he logged before this reads Not checked yet, and stays that way until he looks at that recording again.
Beatport is where you buy it. Spotify, Apple Music, and Deezer play you the tune, Discogs tells you what the release is, and Beatport sells you the download, so that row reads Buy on Beatport. Fluncle searches the store for a recording he has certified and keeps the link only when the record's own ISRC matches the one he already holds, so a near-miss with the right title never gets through. He has only run that search over his own findings so far, so a recording he holds but has not certified reads Not checked yet.
YouTube comes out of the audio, or out of a channel YouTube built itself. When Fluncle buys a recording's audio he searches YouTube for it, pulls down what comes back, and fingerprints it against the official preview. That match is what puts a link here, and the row says so: matched by audio fingerprint. He used to throw the video id away the moment he had it, so the recordings he captured before this have none. He is going back through them a few at a time, his own findings first, pulling the audio down again, fingerprinting it again, and keeping the id this time.
The rest of the archive he answers without buying the whole tune, once he starts on it. There he takes a result on its face only when it sits on one of YouTube's auto-generated artist channels, carries the same artist and the same title, and runs the same length to within three seconds. YouTube builds one of those channels for each artist out of the master the rights holder delivered, so the channel is the credit. He listened to nothing there, and the row says that too: matched by artist, title, and length. A result on any other channel earns none of that, so he buys thirty seconds of it and fingerprints that against the audio he already holds, because only the sound tells a fan re-up from the record. Either way he checks the uploader, and keeps the link only when the channel is the artist's own, one of YouTube's auto-generated artist channels, or the channel of the label that put the record out, because a rip carries the right audio just as well and he would rather show you nothing than send you to one. None of this goes through YouTube's Data API: search.list sits in its own bucket of 100 calls a day that only a compliance audit lifts, so the search rides the same tool that fetches the audio. Every other recording reads Not checked yet, a rip he turned down included.
What is not covered
Every platform below is out for a reason that belongs to the platform, not to what Fluncle got round to. The API answers each of them unsupported.
Tidal. Tidal's developer terms bar displaying what their API returns alongside similar services, storing it in a database, and using it in connection with artificial intelligence. There is no Tidal integration here at all, so Tidal gets no row on the page.
SoundCloud. SoundCloud's API terms bar an online presence dedicated to specific artists or repertoire, playback that aggregates SoundCloud with other services, and caching anything the API returns past the end of a session. Fluncle's archive, with a page per artist, runs into all three. His artist pages do carry a SoundCloud profile where the artist holds one, and that link goes through no API.
Qobuz. Qobuz's API Terms of Use, dated 1 September 2011, bar making the API available to any person who is not a Qobuz user, and bar indexing the service in whole or in part. So there is no Qobuz row.
Bandcamp. There is nothing to match a recording on. A public release page carries no ISRC, no UPC, and no structured data, and the developer API is built for labels and fulfilment partners working their own accounts, so it answers no lookup against Bandcamp's catalogue.
Amazon Music. A request for an invented Amazon Music link comes back as success, the same as a request for a real one, so nothing Fluncle can observe tells the two apart. An honest negative has to be computed from something stored, so he makes no claim about Amazon Music in either direction.
Juno Download. The store has closed. Every Juno link on the web, product pages included, now lands on a farewell page.
The five answers
Per platform and per identifier, the answer is one of five. Three of them are the point. On the page each one reads as a short line of plain status: the method, the date, and what happens next.
| Answer | On the page | What it means |
|---|---|---|
verified | matched by ISRC · confirmed Jul 29, 2026 | Fluncle has the link or the identifier, with how it came to be trusted and when. A row with nothing on file about the method carries its date alone. |
absent | Not found · last checked Jul 12, 2026 · will be checked again | A real look ran to the end and found nothing, with the date, the tally where one is counted, and whether another look is coming. retired means there will not be. |
refused | Not eligible · no length on file | Something about the recording itself stops the look: no length on file, no artist credit to search on. Three of them read as their own verdict instead: Set aside, Held as a duplicate of another recording, and, at the attempt ceiling, Not found · checked as many times as allowed · retired. |
unattempted | Not checked yet | Nobody has ever gone looking. Different from the one above, and the difference matters. |
unsupported | no row | The platform is outside the covered set. The API names it; the page shows only what is covered. |
A lookup that answers only the first leaves you to read silence for the rest. Fluncle can name all five because the machinery that goes looking has counted its attempts all along.
Apple Music is the one place the page and the API disagree about a recording. The page shows an Apple link the way any of Fluncle's own pages show one, honest negatives included. The API answers unsupported for Apple: Apple's rules let him show a link on his own pages, not hand it on for someone else to show.
Two rules hold the honesty in place. Every answer is computed from something stored: where nothing on file settles a question, the answer stays quiet rather than guessing in either direction. And a date says what it marks. The page spells the difference in one word: confirmed is the moment a link was written down, checked is the moment a look finished. Close, but not the same claim, and neither is ever printed as the other.
What it will not tell you
A lookup says one thing about Fluncle's own opinion, and says it as a yes or a no: whether he has certified this recording. One he has certified comes back with its Log ID and its coordinate page; one he has not comes back with its identifiers and its links and nothing else. He puts no name, no rank, and no score on the second kind, here or on any other surface.
From a machine
The track endpoint answers the same thing as JSON. Pass a single - in the path when the key rides a query parameter:
GET /api/v1/tracks/-?isrc=GBXXX0000000
GET /api/v1/tracks/-?mbid=<uuid>
GET /api/v1/tracks/-?spotify=https://open.spotify.com/track/<id>
GET /api/v1/tracks/-?deezer=https://www.deezer.com/track/<id>
GET /api/v1/tracks/004.7.2I?identity=1One kind of key per request. ISRCs may arrive in a batch, below. A key that matches nothing is a 404; a key that is not a well-formed ISRC, UUID, Spotify id, or Deezer id is a 422. The full request and response shapes are in the API reference.
Up to 20 ISRCs at once, comma separated:
GET /api/v1/tracks/-?isrc=GBXXX0000000,GBXXX0000001,GBXXX0000002The answer is the same shape one ISRC gets, because it was already a list: one recordings array holding every match, in the order the keys were sent, each carrying its own ISRC so you can pair an answer back to what you asked. A key that matches nothing brings back no recording, and the whole request is a 404 only when none of them matched. One mistyped ISRC refuses the batch rather than quietly answering nineteen of twenty, and more than 20 is a 422. It saves you round trips, not keys: the meter counts keys, so 20 ISRCs spend 20.
From a browser. Fluncle answers Access-Control-Allow-Origin: * on every public read and on its OPTIONS preflight, so an extension or a web app can call these endpoints straight from the browser. He opens exactly as much as an anonymous request already sees and no more: a * header means no browser attaches cookies, so nothing signed in is reachable this way, and the admin endpoints sit outside it entirely. He sends the header on refusals too, so a 404, a 422, and a 429 each read as themselves rather than as one indistinguishable network error.
Spotify links come back as https://www.fluncle.com/out/spotify/<trackId>, a redirect on Fluncle's own domain. Follow it and you land on Spotify. The one place the raw link is served instead is the structured data on a page, where a link is an identity claim rather than somewhere to go, and a redirect would break the claim.
Fair use
The lookups are metered at 30 keys a minute and 1,000 a day from one place, counted per caller. One lookup is one key, and a batch of 20 ISRCs is 20. Past either, the answer is a 429 and the meter resets on its own. That is the whole policy, it costs nothing, and there is no key to apply for.
If you build on this, two things come with it: say the data came from Fluncle and link back to fluncle.com, and wherever you show a platform link, name that platform and link to it the way its own rules ask. The terms say the same thing in full.
Recording identifiers here include data from MusicBrainz, released under CC0.
If an answer is wrong
Email hey@fluncle.com with the key and what you expected. Fluncle will sort it out.