The Companies House API can bring public company information into the software your team already uses. The useful result is not a clever lookup screen. It is a controlled workflow that removes retyping, shows where the data came from and makes the next business decision easier.
01
Put the public register inside the real workflow
Most people use Companies House by opening a browser, searching for a company and copying a few details into another system. That is perfectly sensible for an occasional check. It becomes slow and inconsistent when the same work happens across every new customer, supplier or broker application.
The Companies House API provides a structured way for software to request information from the public register. Instead of asking somebody to retype a company name, number, status and registered office address, a portal or CRM can retrieve those details and place them beside the rest of the case.
That changes a small lookup into part of a controlled process. The user can search for the correct legal entity, confirm the result and continue with information linked to a company number. The company number matters because names can be similar or change over time, while the registration number gives the workflow a stable reference.
02
Follow one supplier through onboarding
Imagine an operations team onboarding a new supplier. The current form asks for the legal company name, registration number, registered address, directors and trading details. Somebody then checks Companies House, copies the information into the CRM and saves a note saying the company appeared active on that day.
A connected form can start with a company search. The user chooses the right result and the system retrieves the company profile. It can fill the legal name, number, status, incorporation date and registered office address, while keeping the supplier responsible for information that does not belong on the public register.
The workflow can then record when the lookup happened, which company number was selected and what the user confirmed. That audit trail is often more useful than silently filling every box. It explains why the record contains a particular value and gives the team a clear point from which to review later changes.
03
Choose the data that supports the decision
The public data API covers more than a company search. The published specifications include company profiles, registered office addresses, officers, filing history, charges, insolvency information and persons with significant control. There are also search operations for companies, officers, disqualified officers and dissolved companies.
That does not mean every integration should collect everything. The right fields depend on the decision being supported. A checkout asking for an invoice address may only need a company search and profile. A supplier review may also need officers, filing history or insolvency information. A market research tool may need a different subset again.
Collecting less keeps the interface clearer and the responsibility easier to explain. It also avoids turning a useful public lookup into a home-grown due diligence platform without the policies, expertise and review process that such a platform would need.
04
Treat register data as evidence, not a verdict
This is the most important boundary. Companies House is a registry of information supplied to it. Its own disclaimer says that basic checks are carried out, but information placed on the public record should not be treated as verified or validated simply because it appears there.
An active company status therefore answers one useful question, but it does not prove that a supplier is financially strong, trustworthy, insured or suitable for a particular contract. A director record does not replace identity checks. A registered office address is not necessarily the place where the business trades.
Good software keeps that distinction visible. It can show the source, retrieval time and relevant register facts without converting them into a green approval badge that promises more than the data supports. The business still needs its own rules, supporting evidence and people responsible for the final decision.
05
Build the connection as an operational service
A demonstration can call the company profile endpoint and display the JSON response. A production integration needs a little more care. The API key belongs on the server, not inside browser code, a mobile app or a public source repository. Companies House also recommends restricting keys and storing them outside the source tree.
The application should translate the external response into its own small internal model. That model might keep the company number, legal name, status, registered office address and the time of the check. Other Companies House fields can remain outside the core record until a workflow genuinely needs them.
This separation stops the rest of the application becoming tied to every detail of an external response. Companies House advises clients to expect JSON members they have not seen before and not depend on a fixed member order. A narrow mapping layer gives your software one place to absorb those changes.
06
Plan for rate limits, delays and stale data
The default Companies House limit is 600 requests within five minutes. That is generous for many internal workflows, but an inefficient search box can use it surprisingly quickly if it sends a request for every key press. A short delay, sensible minimum search length and cached repeat results reduce waste without making the interface feel slow.
Caching needs a purpose rather than one global expiry time. A list of search suggestions can be cached briefly. A company profile used during an approval may need a fresh lookup and a recorded retrieval time. A historic audit record should not quietly change when the live register changes later.
The integration also needs a useful failure state. If Companies House is unavailable, the user should see that the external check could not be completed. The case can pause, allow a controlled manual route or retry later. It should not silently accept empty company data and make the rest of the process look complete.
07
Test the meaning, not only the connection
The public data APIs are read only and can be tested against live data. Companies House also provides a sandbox for wider API work, especially filing operations that could otherwise change the public register. The correct environment depends on whether the application is only reading public information or is authorised to submit a change.
Integration tests should cover more than a successful active company. Try a dissolved company, a company with missing optional fields, several companies with similar names, a timeout, a rate limit response and a response containing an unfamiliar field. Test what the user sees as well as what the server logs.
The running supplier example should prove that the correct company number is stored, the lookup time is recorded, a failed check remains visible and a user cannot mistake public register data for full approval. Those tests protect the business meaning of the connection, not just its HTTP status code.
08
Start with one decision worth improving
The Companies House API is useful when public company data already sits inside a repeated business task. Common starting points include customer onboarding, supplier checks, broker or installer registration, CRM enrichment, filing alerts and internal research tools.
A native product feature may already solve a simple need. An automation platform can be enough for a low-risk back-office lookup. A custom API integration earns its cost when the workflow needs specific rules, an audit trail, access controls, joined information from several systems or a clear recovery route when the external service fails.
Start with one real handover. Decide what Companies House can supply, what the customer or supplier must still provide and who owns the final decision. The API can remove copying and make public evidence easier to use. The quality of the service still comes from the process built around it.
Useful questions
Questions to ask before adding Companies House data
- Which business decision will the lookup support?
- Which company number and public fields need to be stored?
- What information must still come from the customer, supplier or internal team?
- How will users see the source and time of the Companies House check?
- What must happen if the API is unavailable or returns incomplete data?
- How will the application stay within rate limits and avoid wasteful searches?
- Is the API key kept on the server and outside the source repository?
- Who owns changes when the Companies House response or the business rules evolve?
