MusicBrainz · Rate Limits

Musicbrainz Rate Limits

Machine-readable rate limit policy for the public MusicBrainz Web Service v2 at https://musicbrainz.org/ws/2. MusicBrainz enforces a hard ceiling of one request per second per source IP, regardless of authentication. There are no API keys, so the rate-limit subject is always the source IP. Every request must include a meaningful User-Agent header identifying the application (and ideally a contact URL or email); generic, empty, or library-default User-Agents are subject to outright IP blocking. Commercial users with high volume are expected to replicate the database locally rather than scale the public web service.

Musicbrainz Rate Limits is the machine-readable rate-limit profile for MusicBrainz on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, across the public and supporter tiers, measuring requests_per_second, meaningful_user_agent, and replication_packets.

The profile also includes 7 backoff/retry policies defined and response codes documented for throttled, rateLimitedAlternate, and serviceUnavailable.

Tagged areas include Music, Metadata, Open Data, Rate Limiting, and Etiquette.

4 Limits Throttle: 503
MusicMetadataOpen DataRate LimitingEtiquetteThrottling

Limits

Per-IP Rate Ceiling source-ip
requests_per_second · second
1
User-Agent Requirement source-ip
meaningful_user_agent · instant
1
Per-IP Rate Ceiling (Public WS) source-ip
requests_per_second · second
1
Live Data Feed (No Public WS Limit) contract
replication_packets · hour
-1

Policies

One Request Per Second Per IP
The canonical policy is "All users of the API must ensure that each of their client applications never make more than ONE call per second." This is per source IP, not per application or per authenticated user. Multiple apps sharing an IP must share the same 1 req/sec budget. Bursts above 1/sec are not tolerated.
Meaningful User-Agent Required
Every request must include a User-Agent that identifies the application, its version, and ideally a contact URL or email. The recommended format is "AppName/Version ( contact )", e.g. "MyTagger/1.2.3 ( https://example.com/contact )". Default library User-Agents (urllib, requests, curl) are blocked.
503 With Retry-After
When the rate limit is exceeded, the public web service returns HTTP 503 Service Unavailable with a Retry-After header indicating how many seconds to wait before retrying. Some mirrors and reverse proxies may return HTTP 429 instead. Clients should honour both.
Backoff Strategy
Clients should implement exponential backoff with jitter on any 5xx response, and should pause for at least the Retry-After value before resuming. A persistent rate-limit violation may result in temporary or permanent IP blocking.
Replicate For High Volume
Any caller whose traffic exceeds what the public web service comfortably serves at 1 req/sec is expected to set up a local MusicBrainz replica using the Live Data Feed (free) or to negotiate commercial replication access via the MetaBrainz Supporter programme.
Cache Responses
The canonical data changes slowly; responses include standard HTTP caching headers and clients are expected to cache aggressively (especially MBID lookups, which are immutable references).
No API Key
The public web service does not require or accept an API key. Authentication via HTTP Basic or OAuth 2.0 is only required for user-specific reads (private collections, user tags/ratings) and for submission endpoints; it does not raise the rate ceiling.