The Companies House API is a good thing. It is free, it is comprehensive, it covers every registered UK entity, and it is publicly accessible without a business justification or a data licensing agreement. For a public register of commercial information, this is not the default globally, and it is worth being clear that the UK's openness here is genuinely useful. The problem is not the API. The problem is the gap between what the API returns and what a production compliance or research pipeline actually needs, and how reliably teams underestimate that gap when they start building.
This note is about the gap: what the raw data does and does not contain, what building on top of it actually involves, and where the work is heavier than it first appears.
What the API gives you
The standard Companies House API provides per-company lookups across a useful range of data types. Company profiles contain the registered name, number, address, incorporation date, SIC codes, and filing status. Officers returns cover current and resigned directors and secretaries, with appointment and resignation dates. The PSC endpoint returns the persons with significant control register for each company. Filing history gives you a list of submitted documents with links to the originals. Insolvency records cover liquidation, administration, and dissolution history.
For a single lookup, this is excellent. You can retrieve a company's current PSC, check its directors, and pull its filing history in a few API calls. The data is structured, well-documented, and updated continuously as filings arrive at Companies House. The free tier allows 600 requests per five-minute window, and the streaming API provides bulk access to the full dataset without per-request limits.
Where the raw data stops
The API returns records as they appear in the register. It does not resolve those records into a usable structure. The first practical consequence of this is entity resolution. The same individual appears in Companies House filings under dozens of name variations, address formats, and date-of-birth representations, because filings are submitted by different agents over many years with no standardisation requirement. John William Smith, J. W. Smith, and J Smith filed under different service addresses are potentially the same person. The API returns all three as separate records. Determining that they refer to the same natural person is a problem the API does not address.
The second consequence is chain resolution. If a company's PSC is itself a company, the API returns the corporate PSC record. It does not resolve through to the natural person who controls that company. A pipeline that needs to identify the ultimate beneficial owner of its counterparties must implement its own traversal: call the PSC endpoint for the corporate PSC, determine whether the result is a natural person or another entity, and repeat until the chain terminates. For structures of any depth, this is a non-trivial engineering problem, and for chains that cross into other jurisdictions it requires accessing and integrating other registers.
The historical state problem
The API returns the current state of a record. Amendments are recorded in the filing history, but reconstructing what a company's PSC register looked like on an arbitrary past date requires reading through amendment events in chronological order and building the historical state from the sequence. There is no endpoint that accepts a date and returns the register as it was then.
For compliance teams doing onboarding checks on current counterparties this is usually acceptable. For teams conducting due diligence on completed transactions, or investigations into relationships that were formed under a different ownership structure, the absence of a temporal query layer is a material gap. The working is significant: a five-year filing history on a complex entity, reconstructed manually to answer a question about the ownership structure as it stood at closing, is hours of analysis against a linear sequence of amendment documents.
Production reliability and rate limits
The 600-requests-per-five-minute free tier is sufficient for manual lookups and light-duty pipelines. It is not sufficient for a production KYB process that needs to screen hundreds of counterparties on demand, or a research pipeline that needs to query a large corpus of entities. The streaming API provides full-dataset access without per-request limits, but consuming it requires infrastructure: a processing pipeline to ingest the event stream, storage to hold the full dataset, and the indexing work to make it queryable at the latency a production system requires.
Teams that start with the free API and scale into production volume typically reach the rate limit before they have resolved the entity resolution and chain resolution problems, and find themselves building a data infrastructure project that was not in the original plan. This is not a criticism of Companies House; the API was not designed as a production database. It is a public record access mechanism. The gap between those two things is real, and it tends to be discovered late.
What building on it actually looks like
A production pipeline on top of the Companies House API typically involves entity resolution to match records across filings, a traversal layer to resolve ownership chains through corporate PSCs, a historical state layer to answer point-in-time queries, integration with other data sources for cross-border structures, and infrastructure to handle bulk access and query at scale. Each of those is a separable engineering project; built together they constitute a significant investment before the underlying data can answer the question a compliance or research team is actually asking.
Teams that have built this, or are building it, will recognise the problem. For teams evaluating whether to build it or find a data source that has already done the work, Briefed Atlas is the latter: the resolved ownership layer, with entity resolution applied, chains traversed to natural persons, source filings linked to every record, and the graph queryable across time. The full account of what the Companies House API covers and where it stops is at the Atlas Companies House API reference.