Companies House API Rate Limits — and How to Never Hit Them

What is the actual rate limit?

Companies House enforces a limit of 600 requests per 5 minutes per API key. That works out to 2 requests per second on average. If you exceed this, the API returns an HTTP 429 Too Many Requests response and stops serving data until the window resets. There is no official burst allowance — the counter is a rolling window, not a fixed bucket, so sustained throughput matters more than short spikes.

The limit applies per key, not per IP. If you have multiple applications or services sharing one key, their usage is pooled. At 600 req/5 min, a batch job processing 1,000 companies would drain your entire allowance in under 9 minutes — and that assumes every call succeeds first time.

What does a 429 response look like?

The Companies House API returns a plain 429 with no Retry-After header in most cases. You will not be told when the window resets. Your only option is to back off and retry after 5 minutes. In production systems without retry logic, a 429 usually manifests as a silent data gap — your app receives an error, logs it (or does not), and moves on, leaving you with incomplete records.

Common causes of hitting the limit

• Bulk lookups. Enriching a CRM export or screening a list of counterparties in one go. Even at modest scale — say, 200 companies — you will consume a third of your 5-minute budget in a single batch.
• Polling for fresh data. If your application re-fetches company records on every page load or request, you are burning quota on data that almost certainly has not changed. Companies House records update infrequently — most companies file once a year.
• Multiple services sharing one key. A backend API, a scheduled enrichment job, and an ad-hoc analyst script all hitting Companies House under the same credential adds up fast.
• Retry storms. Naive retry logic with no exponential backoff turns a transient 429 into a cascade — every retry hits the already-full window and generates another 429.

How caching eliminates the problem

The real solution is not smarter retry logic — it is not making the upstream call in the first place. Registrum sits between your application and Companies House, serving cached responses for the vast majority of requests. Company profiles are cached for 24 hours; financial data for 7 days. The underlying CH API is only called once per company per cache window, regardless of how many times your application requests the same company.

Every Registrum response includes an X-Cache-Status header so you can see exactly what happened. A value of HIT means the response came from cache and no CH API quota was consumed. MISS means Registrum fetched fresh data and cached it for subsequent callers. If the CH API is down or rate-limited, Registrum falls back to stale cache rather than returning an error — your application stays up.

Example: seeing the cache in action

# First call — fetches from Companies House, caches the result
curl -i -H "X-API-Key: reg_live_..." \
  "https://api.registrum.co.uk/v1/company/00445790"

# Response headers include:
# X-Cache-Status: MISS
# X-Cache-TTL: 86400
# X-Request-ID: 7f3a9c...

# Second call to the same company — served from cache instantly
curl -i -H "X-API-Key: reg_live_..." \
  "https://api.registrum.co.uk/v1/company/00445790"

# Response headers:
# X-Cache-Status: HIT
# X-Cache-TTL: 83147   (seconds remaining in cache window)
# X-Request-ID: 4e1b2d...

A cache HIT consumes zero Companies House API quota. Your application can call the same endpoint thousands of times per day without touching the rate limit.

Practical recommendations

If you are calling the Companies House API directly and need to stay within limits: implement exponential backoff with jitter on 429 responses, add a local in-memory cache for records fetched within the last hour, and split bulk jobs into batches of 100 with a 30-second pause between them. That keeps you under the rolling average without adding significant latency.

If you would rather not manage any of this, use Registrum. The caching, circuit breaking, and stale-fallback logic are built in. Your application calls one endpoint and gets a consistent response — no quota management required.