A MusicBrainz API Alternative for Cross-Platform Track Metadata

First, the disclosure

SonoVault sources data from MusicBrainz. It is one of the six platforms in our catalog, it is credited on our data sources page, and a good part of what makes SonoVault work exists because the MetaBrainz community spent two decades building an open, carefully modelled music database. This article is not a takedown. It is an answer to a question we get from developers who already use MusicBrainz and love it: at what point do you need something different, and what does that something look like?

What MusicBrainz gets right

• Open data. The core dataset is freely licensed, and full database dumps are published for anyone to download. No commercial API can honestly claim to beat that on openness.
• Depth of modelling. Works, recordings, releases, release groups, artist credits, engineers, recording venues. If you need to know who played bass on a 1974 session, MusicBrainz is where that answer lives.
• Community correction. Errors get found and fixed by people who care, with an edit history to prove it.
• It is free. Both the data and the public API cost nothing.

The four walls you eventually hit

Every team we have talked to that went looking for a MusicBrainz API alternative hit one of the same four walls.

1. The rate limit. The public MusicBrainz API asks clients to hold to an average of one request per second. That is a fair ask for a donation-funded service, but it puts a hard ceiling on what you can build against it: enriching a 100,000-track catalog takes over a day of continuous polite polling, and a production feature that fans out user requests to MusicBrainz will throttle the moment it gets traffic.

2. Community-shaped coverage. Volunteer editors go where volunteer interest goes. Canonical rock and classical catalogs are covered superbly; fast-moving electronic releases, DJ-pool edits, and regional catalogs can lag or never arrive. A gap only gets filled when someone shows up to fill it.

3. No systematic streaming-platform IDs. MusicBrainz can hold URL relationships to streaming services, but they exist only where an editor added them. There is no first-class, reliably populated Spotify, Apple Music, Tidal, or Beatport ID on a recording. If your product needs “open this track on the user's platform” or cross-platform reconciliation, you end up joining against other sources anyway.

4. Scaling means hosting a mirror. The sanctioned way past the rate limit is running your own MusicBrainz instance with live data feed replication. That works, and plenty of companies do it, but now you are operating a Postgres cluster, a replication pipeline, and a search index for a database that is not your product.

The two read paths side by side

Two of those rows favour MusicBrainz, and honestly so. If you need open data you can edit, or the deep relationship graph, stay put. The SonoVault case is the other five rows: a hosted catalog of 90M+ tracks merged from Spotify, Apple Music, Tidal, Beatport, Discogs, and MusicBrainz itself, keyed by ISRC, behind one x-api-key header and a documented REST surface.

# One MBID in, every platform out. Same call works with ?isrc= or ?spotify_id=.
curl "https://api.sonovault.now/v1/tracks/links?musicbrainz_id=b3f6f5a0-3d1c-4be0-8e28-0a1f3e2c9d10" \
  -H "x-api-key: YOUR_API_KEY"

{
  "track_id": 123,
  "title": "Harder Better Faster Stronger",
  "isrc": "GBDUW0000059",
  "links": [
    { "source": "spotify",     "external_id": "5W3cjX2J3tjhG8zb6u0qHn", "url": "https://open.spotify.com/track/…" },
    { "source": "applemusic",  "external_id": "697195787",  "url": "https://music.apple.com/song/…" },
    { "source": "tidal",       "external_id": "3789027",    "url": "https://tidal.com/browse/track/…" },
    { "source": "beatport",    "external_id": "12345679",   "url": "https://www.beatport.com/track/-/…" },
    { "source": "musicbrainz", "external_id": "b3f6f5a0-3d1c-4be0-8e28-0a1f3e2c9d10", "url": "https://musicbrainz.org/recording/…" }
  ]
}

// No MBID? Search by artist + title. Fuzzy matching handles the noise.
const res = await fetch(
  `${BASE}/v1/tracks/search?artist=Daft+Punk&title=Harder+Better+Faster+Stronger`,
  { headers: { "x-api-key": API_KEY } }
);
const { results } = await res.json();

{
  "results": [
    {
      "id": 123,
      "title": "Harder Better Faster Stronger",
      "releases": [
        {
          "id": 1,
          "title": "Discovery",
          "artist": { "id": 1, "name": "Daft Punk" },
          "label": { "id": 10, "name": "Virgin Records" },
          "release_date": "2001-03-12"
        }
      ],
      "artists": [{ "id": 1, "name": "Daft Punk", "is_primary": true, "is_remixer": false }],
      "isrc": "GBDUW0000059",
      "duration": 224,
      "genre": ["House"],
      "subgenre": ["French House"]
    }
  ],
  "next_cursor": null
}

# Recording → composition. MLC-backed; not part of the standard track payload.
curl "https://api.sonovault.now/v1/tracks/iswc?isrc=GBDUW0000059" \
  -H "x-api-key: YOUR_API_KEY"

{
  "sonovault_id": 123,
  "isrc": "GBDUW0000059",
  "iswcs": [{ "iswc": "T0701427997", "title": "HARDER BETTER FASTER STRONGER" }]
}

When to stay on MusicBrainz

• Your volume genuinely fits inside a request per second, and free matters more than latency.
• You need the deep relationship graph: session credits, works, recording places, edit history.
• You want to contribute corrections back to an open commons rather than consume a read-only API.
• You are happy operating a mirror and the ops cost is worth the control.

If instead your wall is rate limits, streaming IDs, or coverage of fast-moving catalogs, that is the job SonoVault was built for. The same evaluation for other providers: a Discogs API alternative, a Gracenote API alternative, and for the Spotify Web API specifically, the full SonoVault vs Spotify API comparison.