Rate limits
Two limits apply to every key, and one of them is measured in 30-day windows.
Two independent limits sit in front of the API. Both are enforced on your account, so they are shared by every key you hold.
| Limit | Window | Applies to |
|---|---|---|
| Requests per minute | rolling 60 seconds | all keys on the account |
| Requests per 30-day window | 30 days, fixed reset | all keys on the account |
The per-minute limit protects the service from bursts. The 30-day limit is the one that will surprise you: it is set when your first key is created and is not raised when you buy credits, upgrade, or create more keys.
Exhausting the 30-day allowance returns 401, not 429
When the 30-day allowance runs out, every key on the account starts returning
401 UNAUTHORIZED with no Retry-After and no indication that a limit was hit.
Creating a new key does not help — the allowance belongs to the account. If a key that
worked yesterday returns 401 today and you have not revoked it, this is almost
certainly why. Contact sales@registercheck.de to have
the allowance raised.
Response headers
Successful responses carry the per-minute limit state:
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 58
X-RateLimit-Reset: 2026-09-15T08:41:00Z
X-RateLimit-Provider: UnkeyThese headers describe the per-minute window only. The 30-day allowance is not currently exposed on any response.
Staying inside the limits
- Serialise your calls or cap concurrency at around 40 requests per minute; the per-minute ceiling is shared, so two workers at 40 each will trip it.
- Cache company records. Register entries change on the order of once a year, not once a minute — see Monitoring for the supported way to learn about changes instead of polling.
- Prefer one filter call over many single-company reads when you are building a list.