What 600 requests per 5 minutes really costs a batch job

The Companies House API allows 600 requests per five minutes. That number is published, and it is the least interesting thing about the limit. Three properties that are not published, or not obvious, decide whether a batch job finishes this afternoon or next week.

We have been running against this limit since February 2026, including the request-coalescing layer we added on 13 February, and the notes below come from that rather than from the docs.

1. Registering more keys does not help

The limit is enforced per account and per IP address. The per-IP part is not in the documentation; we established it in March 2026 after watching a second key on the same host gain nothing at all.

This matters because "just register another key" is the first thing most teams try when a batch job is too slow, and it is wasted work. If your job runs from one machine, or from a cluster behind one NAT gateway, all of it shares one ceiling regardless of how many keys are in play.

The corollary catches people scaling horizontally: putting your worker on four replicas does not give you four allowances. It gives you four processes competing for one, each unaware of the others, which is how a well-behaved system starts getting throttled without anyone changing the rate.

2. It slides, it does not reset

The window is a rolling 300 seconds, not a clock-aligned block.

The practical difference is large. If you fire 1,200 requests in ten seconds, you are not waiting until the top of the next five-minute block. You are throttled for roughly 290 seconds, because the window keeps carrying your burst until it ages out. Code that computes "requests remaining this minute" against a clock is modelling a limit that does not exist, and it will be surprised.

Steady pacing beats bursts, even when the burst is nominally within budget.

3. One lookup is not one request

This is the one that ruins estimates. Asking for a company's officers is not a single call: the officer list gives you appointments, and getting the detail behind each officer fans out to one call per officer, including resigned ones. A large old company is expensive: a cold lookup of Tesco's officers costs upwards of 50 calls.

So a job over 1,000 companies is not 1,000 requests. Depending on how many officers those companies carry and how much history they have, it can be several times that. The arithmetic below is arithmetic, not a measurement, and your numbers will differ with your company mix:

Job	Requests at 1 per company	Realistic with officer fan-out
1,000 companies, profile only	1,000	1,000
1,000 companies, profile + officers	1,000	5,000-20,000+
At 600 per 5 min	~8 minutes	~40 minutes to several hours

The number that ruins an afternoon is never the one in the plan.

What we do about it

Three things, none of them clever:

A negotiated ceiling. Our Companies House key is raised to 1,200 per five minutes, and we hold ourselves to a 1,000 budget so that we degrade to cached data before we approach the real ceiling rather than after. That headroom is a shared pool across everyone using Registrum, not a per-customer allowance, which is why we shed background traffic before customer traffic when it gets tight.

Coalescing. Concurrent requests for the same company become one upstream call. In a batch over a client book with shared directors and group structures, the same companies come up more than once.

Caching with a deliberate staleness policy. When the upstream budget is exhausted, serving data that is a few hours old beats failing the request, and we say which it was in the response rather than pretending it was live.

If you are hitting the limit today

You have three real options, in increasing order of effort:

1. Pace, do not burst. A steady trickle under the limit finishes sooner than a burst plus throttling. This is free and usually enough.
2. Ask Companies House for an uplift. They do grant them. It costs an email and some patience, and it is the right answer if you are building your own integration.
3. Use something that has already done this. That is us, and this is the one paragraph of sales in the article: our API sits on the negotiated ceiling with the coalescing and caching already built, so a batch job is a batch job rather than a rate-limit project.

Option 2 is genuinely fine. If your volume is modest and your patience is not, option 1 is free.

Verifying this yourself

• The published 600 per 5 minutes is in the Companies House developer documentation at developer.company-information.service.gov.uk.
• The per-IP behaviour is testable: register a second key, run both from the same host, and watch the combined throughput stay flat.
• The officer fan-out is visible in any request log: count the calls behind one officer lookup on a company with a long history.