The Odesli API in 2026: Where It Falls Short, and the Alternative We're Building

If you build software that turns a Spotify link into an Apple Music link, a Tidal link, or a YouTube link, there is a good chance you reached for the Odesli API (also known as the song.link API). For years it was the obvious default. In 2026 that default deserves a second look.

This is not a "the tool is dead" post. Odesli's public API is up, and it answers. But when we measured what it actually returns, the output was thinner than most developers expect, and the commercial terms around it have not kept pace with what production software needs. Below is exactly what we tested, what we found, and the alternative we are building at SongPort.

First, the honest part: Odesli still works

Let us be precise, because precision is the whole point of this post.

On 21 July 2026 at 13:33 UTC we called the public endpoint https://api.song.link/v1-alpha.1/links with two ordinary Spotify tracks. Both requests succeeded. Both returned a valid JSON response with a pageUrl and a set of platform links. The service was not offline, not rate-limited into oblivion, and not returning errors.

So the problem is not that Odesli is broken. The problem is what a successful response contains.

What we measured: the response is thinner than you think

Here is what those two successful calls returned, and what was missing.

Read that missing column again. For both tracks, the response carried plenty of smaller stores but no Apple Music, no iTunes, no YouTube, no YouTube Music, and no SoundCloud.

For most real products, those are not edge cases. Apple Music and YouTube are two of the largest destinations a listener might pick. If your feature pastes a Spotify link and promises "open this anywhere," a response that silently drops Apple Music and YouTube is a response that quietly breaks your feature. The service runs. The result is just impoverished.

We are describing our own reproducible measurement here, taken at a specific moment, against specific tracks. Odesli's coverage can change, and you should run the same test yourself before you decide. That is exactly why our alternative ships with a public demo you can point at the same link.

The commercial terms have not kept up

Coverage is only half of it. The other half is how you are allowed to use the thing in production.

Based on Odesli's public documentation and our own use, three constraints stand out for anyone building a real integration:

First, there is no self-serve paid plan. There is no page where you enter a card, pick a volume tier, and get a higher, guaranteed rate limit for commercial use. For a hobby script that is fine. For a product with a roadmap, "email us and hope" is not a dependency you want under your feature. Second, the throughput sits around 10 requests per minute. That ceiling is comfortable for occasional lookups and uncomfortable the moment a real userbase hits your feature. Ten per minute is not a throughput you build a chat integration or a bulk importer on. Third, there is an attribution requirement. You are expected to credit Odesli. Reasonable for a free public service, but a constraint some products would rather pay to remove.

None of these make Odesli a bad free tool. They make it an awkward foundation for a paid product. That gap, an API that people already lean on but cannot cleanly build a business on, is the reason we started building an alternative.

The alternative: an ISRC-first music link API, open for testing

SongPort started as a free consumer converter. You can still paste a link at songport.link and get a universal page in seconds, the same way you would with any smart link tool. If you want the background on the format itself, we wrote a full explainer on how universal music links actually work.

The engine underneath that converter is what we are now opening up as an API. It matches on ISRC first, the International Standard Recording Code that every commercially released recording carries. ISRC identifies the recording itself, not a fuzzy title-and-artist guess, so when a platform exposes an ISRC the match is exact rather than approximate. When a platform does not expose one (YouTube is the notable case, since it has no ISRC to match on), we fall back to title matching and flag that link as a search fallback rather than pretending it is a certain deep link. You always know what you got.

Here is the difference on the same Spotify track we tested above:

You do not have to take the table on faith. The SongPort developers page runs a live demo against the exact same code path a paying key hits. Paste a link, see every field, and compare it to what Odesli gives you for the identical URL.

We are being deliberate about "open" and "tested"

Two things we want to be straight about, because overselling a young API helps no one.

The API is open, but it is a testing phase, not a finished product. Keys are issued by hand right now, on purpose. That lets us watch every conversion, see where matching is strong and where it is not, and fix it against real traffic before we flip on self-serve billing. We are running extensive testing precisely so that the response schema becomes a contract you can build on without it shifting under you. If you want in, the fastest path is the waitlist on the developers page.

The scope is single tracks, honestly labelled. This resolves individual recordings across the major platforms. Playlists, albums, and podcasts are out of scope today. YouTube links come from title matching, so we mark them as good rather than guaranteed. When a catalogue genuinely does not carry a track, you get a search URL, not a fabricated deep link. Knowing which links are certain and which are best-effort is worth more than a response that hides the difference.

If you want the request and response shapes, the API documentation has the endpoint, the auth model, and the field-by-field schema. It is a server-to-server API: your key lives in your backend, never in browser code.

Who this is for

You are a fit for the SongPort API if:

• You are building a feature that converts music links at more than a trickle, and 10 requests per minute is a wall.
• You need Apple Music and YouTube in the response, reliably, not sometimes.
• You want to pay to remove the attribution requirement and get a rate limit you can plan around.
• You would rather integrate against an API whose team answers, watches your traffic, and treats the response schema as a promise.

You are probably fine on Odesli's free tier if you are running an occasional personal script, you do not mind crediting them, and the platforms it happens to return are the ones you care about.

How SongPort compares to the rest

Odesli is not the only name in this space. If you are weighing options at the consumer level rather than the API level, we keep an up-to-date comparison of free music smart link tools, and a separate look at the best smart link tool for indie artists in 2026. For the specific task of turning a Spotify link into an Apple Music link, there is a dedicated Spotify to Apple Music guide.

Try it against your own link

The strongest argument we can make is one you run yourself. Take a Spotify track that matters to you, call the Odesli API, and note which platforms come back. Then paste the same link into the SongPort demo and compare. If Apple Music and YouTube matter to your product, the difference will be obvious in one test.

When you are ready to build on it, join the API waitlist on the developers page and read the API docs.

FAQ

Is the Odesli API down or discontinued? No. As of our test on 21 July 2026, the public API at api.song.link was up and returning valid responses. The issue we found is coverage: the successful responses omitted Apple Music, iTunes, YouTube, YouTube Music, and SoundCloud for the tracks we tried. Run the same test yourself, since coverage can change over time.

What is the best Odesli API alternative for developers? If you need Apple Music and YouTube in the response, a rate limit you can plan around, and no attribution requirement, the SongPort API is built for exactly that gap. It is open for testing now via a waitlist on the developers page.

Does the SongPort API use ISRC matching? Yes. It matches on ISRC first, the recording's actual identifier, and only falls back to title matching when a platform does not expose an ISRC (such as YouTube). Those fallback links are labelled as search matches so you always know their confidence level.

Is the SongPort API self-serve yet? Not yet, and we would rather say so plainly. Keys are issued by hand during this testing phase so we can validate matching against real traffic before turning on self-serve billing. Self-serve is on the roadmap. Join the waitlist to be early.

Can I use it in the browser? No. It is a server-to-server API. Your key belongs in your backend, never in client-side code. See the API documentation for the auth model.

Do universal music links affect streaming royalties? No. A universal link redirects to the official track page on each platform, so streams count exactly as they would from a direct link. We cover this in detail in our guide to how universal music links work.