Rate Limiting
brin API rate limits: 60 requests per minute sustained, burst of 10. IP-based, no auth required. Use /bulk for batch lookups.
the API enforces IP-based rate limiting on all endpoints. no auth required — limits are per client IP. one client hitting the limit doesn't affect others.
##limits
| Parameter | Value |
|---|---|
| Sustained rate | 60 requests per minute (1 req/s) |
| Burst allowance | 10 requests (sent instantly) |
| Replenish rate | 1 token per second |
each IP gets an independent quota. once the burst is exhausted, requests are throttled to 1 per second until tokens replenish.
the /bulk endpoint counts as a single request regardless of how many lookups it contains (up to 100). use it to stay well within limits when checking multiple artifacts.
##response headers
every API response includes rate limit headers so clients can track their quota:
| Header | Description |
|---|---|
x-ratelimit-limit | max requests allowed per minute |
x-ratelimit-remaining | requests remaining in the current window |
x-ratelimit-after | seconds until the next request is allowed (0 when not throttled) |
##rate-limited responses
when the limit is exceeded, the API returns HTTP 429 Too Many Requests:
the response includes a Retry-After header indicating how many seconds to wait:
##client IP detection
behind reverse proxies, the client IP is extracted in this order:
X-Forwarded-ForheaderX-Real-IPheader- TCP peer address (fallback)
requests routed through load balancers and CDNs are correctly attributed to the originating client.
##best practices
- use
/bulkfor batch lookups — a single bulk request with up to 100 items counts as one request against your quota. - read the response headers — check
x-ratelimit-remainingto know when you're approaching the limit. - honor
Retry-After— when you get a 429, wait the indicated seconds before retrying. - avoid tight loops — if you need to look up many artifacts sequentially, add a small delay or batch them with
/bulk.
On this page