How to Scrape MusicBrainz Artists & Releases in 2026

MusicBrainz is the canonical open music encyclopedia — the registry that assigns a stable MBID to every artist, release and recording, and the one most other music databases quietly reference. Its JSON Web Service is fully open and CC0-licensed, so the data is free to use. The catch is the rate limit: MusicBrainz asks clients to send no more than one request per second, which turns any bulk extraction into an exercise in patient, polite pagination. Naive scripts that fire concurrent requests get throttled or blocked. This guide covers how the MusicBrainz Web Service is structured, how to page through it within the rate limit, and what clean, normalized records look like.

What’s worth extracting

Each result normalizes to a flat object with 12 fields, whichever entity type you search:

• Identity — id (the MBID — MusicBrainz’s globally unique, stable identifier), name (artist name, release title, recording title or label name), type (e.g. “Person”, “Group”, “Album”, “Single”).
• Provenance — mode (which search was used: artistSearch, releaseSearch, etc.) and url (direct MusicBrainz page for the entity).
• Geography — country (ISO 3166-1 alpha-2 code like “GB”, “US”, “JP”) and area (associated geographic area).
• Dates — beginDate (formation, release or founding date) and endDate (dissolution or ended date, when applicable).
• Disambiguation — disambiguation (a parenthetical note distinguishing same-named entities) and score (relevance match, 0–100).
• Genre — tags (comma-separated, community-sourced genre and style tags).

The MBID is the field that makes MusicBrainz worth scraping: it’s stable, globally unique, and the correct canonical key for joining music entities across databases. For genre or catalog work, tags, type and country carry the analysis.

How the MusicBrainz Web Service works

The actor calls the official JSON Web Service at musicbrainz.org/ws/2/. You pick a mode — artistSearch, releaseSearch, recordingSearch or labelSearch — and give it a query. It paginates via offset in batches of up to 100, inserting a delay between requests to honor the rate limit, and retries transient errors with exponential back-off.

A plain search by artist name:

{
  "mode": "artistSearch",
  "query": "Radiohead",
  "maxResults": 100
}

The real power is that the query field accepts Lucene-style field syntax, not just plain text. This is how you get precision instead of a fuzzy keyword dump. To find only studio albums credited to a specific artist:

{
  "mode": "releaseSearch",
  "query": "artist:Radiohead AND type:album",
  "maxResults": 200
}

For label research, combine a name and a country clause: label:EMI AND country:GB. The field names (artist:, type:, country:, label:) map onto MusicBrainz’s schema, so a well-formed Lucene query is far cleaner than filtering a broad result set after the fact.

The four modes

Each mode targets a different entity in the MusicBrainz data model, and the name field means something different in each:

• artistSearch — people and groups. name is the artist name; type distinguishes “Person” from “Group”; beginDate / endDate are formation and dissolution dates.
• releaseSearch — specific released versions of an album or single. name is the release title; type is the release group type (“Album”, “Single”, “EP”). Pair with an artist: clause to scope to one artist’s discography.
• recordingSearch — individual recorded tracks (distinct from the releases they appear on). Useful when you care about the recording itself across multiple releases and compilations.
• labelSearch — record labels and imprints. name is the label name; combine with country: to map a region’s labels.

Match the mode to the entity you actually want — searching recordings when you mean releases returns the wrong granularity.

▶ Run the MusicBrainz Scraper on Apify — search artists, releases, recordings or labels with Lucene queries, and export normalized metadata with MBIDs to CSV or JSON. No API key, no login.

The access reality

There’s no authentication wall here — the Web Service is public and requires no key or account. The single dominant constraint is throughput, and it shapes everything about how you plan a run:

• One request per second, enforced. MusicBrainz’s usage policy caps clients at ~1 req/sec. The actor inserts a 1.1-second delay between requests to stay compliant. This is not something to “optimize away” — bypassing it gets your traffic throttled or blocked, and it’s a term of use, not just a suggestion.
• The rate limit dictates run time, not the data volume. Because pages come at roughly one per second and each holds up to 100 results, 100 rows take about a minute and 1,000 rows take about ten. A 10,000-result extraction is a multi-hour job. Plan maxResults around the clock, not just around how much data you want.
• A descriptive User-Agent is required. MusicBrainz policy mandates a meaningful User-Agent header identifying the client; the actor sends one automatically. Anonymous or spoofed agents risk being blocked.
• Coverage is community-curated and uneven. MusicBrainz is edited by volunteers, so endDate, country and tags are frequently null for lesser-documented artists and releases. Popular entities are richly annotated; obscure ones may have little beyond a name and MBID.
• 10,000 results per run is the practical cap. The actor paginates by offset up to 10,000 rows or until the result set is exhausted.

Because the rate limit is the bottleneck and the API is public, proxies are optional — the default configuration runs without them.

Example output

One artist record with full metadata:

{
  "id": "b10bbbfc-cf9e-42e0-be17-e2c3e1d2600d",
  "name": "The Beatles",
  "type": "Group",
  "country": "GB",
  "disambiguation": "",
  "score": "100",
  "area": "United Kingdom",
  "beginDate": "1960",
  "endDate": "1970",
  "tags": "rock, pop, british invasion, classic rock, merseybeat",
  "mode": "artistSearch",
  "url": "https://musicbrainz.org/artist/b10bbbfc-cf9e-42e0-be17-e2c3e1d2600d"
}

The MBID in id and url is what you’d store as the canonical key; score: "100" marks an exact match to the query.

Who uses this

• Music researchers and academics who need structured discography or artist data in bulk for analysis.
• Streaming and playlist apps enriching track or artist metadata against a trusted open registry, keyed on MBID.
• Data journalists covering music-industry trends, genre evolution, or country-level artist distributions.
• Record-label teams auditing catalog coverage and cross-referencing MusicBrainz IDs with internal systems for deduplication.
• Developers and data engineers building music knowledge graphs, recommendation systems or tagging pipelines on a canonical entity layer.

Cost and effort: build vs. managed

Hitting the MusicBrainz Web Service directly is easy; doing it correctly at scale is where the effort hides. You need a rate-limiter that reliably holds under one request per second, offset pagination, retry with back-off for transient failures, a compliant User-Agent, and the normalization that flattens MusicBrainz’s nested entity JSON into the flat 12-field record. Get the rate-limiting wrong and you’re blocked; get the retries wrong and long runs die halfway.

The managed actor is pay-per-result — a fraction of a cent per row plus a trivial start fee. The dollar cost of a large extraction is negligible; the real cost the actor removes is the wall-clock discipline and the rate-limit engineering. You set maxResults, walk away, and collect a clean dataset.

Common pitfalls

MusicBrainz-specific gotchas:

• Don’t fight the rate limit. The ~1 req/sec cap is the defining constraint. Size runs around it and never try to parallelize past it — you’ll get blocked, not faster.
• Use Lucene syntax for precision. A plain title query in releaseSearch returns noise; artist:Radiohead AND type:album returns the actual albums. Learn the field names — they’re the difference between clean and messy output.
• Filter on score downstream. Search is fuzzy, so low-score rows are loose matches. Keep score >= 80 when you want high-confidence results only.
• Always inspect disambiguation when deduplicating. Same-named entities are common in music; the disambiguation note is how MusicBrainz tells them apart, and ignoring it corrupts a dedup.
• Date formats vary. beginDate and endDate may be a full YYYY-MM-DD, a YYYY-MM, or just YYYY. Parse defensively — don’t assume a fixed format.
• Tags are incomplete for obscure entities. Community tagging is thorough for famous artists and thin for the long tail. Great for genre analysis on well-known music, unreliable as a completeness guarantee.
• Recordings and releases aren’t the same thing. A recording is a single recorded performance; a release is a published product (an album, single or EP) that may contain many recordings, and the same recording can appear on many releases. Search the wrong one and your counts and joins will be off — pick the entity that matches your actual question.
• Proxies are optional here. Because the ~1 req/sec limit is the bottleneck rather than IP reputation, the default configuration runs without proxies. Adding them doesn’t buy you speed — only the rate limit governs throughput.
• MBID is your join key, not the name. Names collide and change; the MBID is stable and unique. Store it as the canonical identifier in any downstream database.

Wrapping up

MusicBrainz gives you a canonical, openly licensed music registry with stable identifiers — the access is free and unauthenticated. The engineering that matters is the rate-limit-respecting pagination, the retry logic, and the normalization, all under a hard one-request-per-second ceiling that makes bulk runs a patience game. If you need a handful of lookups, the Web Service is straightforward. If you need thousands of normalized records with MBIDs, delivered as a spreadsheet without babysitting a throttled crawler, a managed actor handles it.

▶ Open the MusicBrainz Scraper on Apify — one run yields up to 10,000 normalized music records with MBIDs, types, countries, dates and tags, exportable to CSV, Excel or JSON. No API key, no login. Start on Apify’s free monthly credit.