Using the Companies House API for UK customer onboarding and KYC

Companies House can tell your application that a company exists, its registration number, status, registered office, officers, people with significant control, filing history and other public information. It cannot, by itself, prove that the person completing your form controls that company or has authority to act for it.

That distinction determines whether a Companies House integration becomes a useful onboarding tool or a source of incorrect customer records.

After working with Companies House data in UK accounting, company data and CRM projects, our preferred model has four stages: discover possible companies, resolve the correct legal entity, verify the organisation and the person acting for it, then monitor important changes after onboarding. The API call is the easy part. Entity matching, verification policy and safe synchronisation require most of the design work.

What the Companies House API provides

The Companies House Public Data API returns live register data for companies covered by the Companies Act 2006. The core company profile can include the legal name, company number, status, incorporation date, company type, registered office, previous names, SIC codes and links to related resources. Those resources include officers, people with significant control, filing history, charges and insolvency information. Companies House API Company profile resource

A typical onboarding integration uses these endpoints:

The public API uses an API key sent through HTTP Basic Authentication. Companies House currently allows 600 requests within a five-minute period for the standard API. Requests above the limit receive a 429 Too Many Requests response for the remainder of the window. Authentication guidance Rate-limit guidance

Company lookup and KYC answer different questions

The term KYC is often used loosely in product requirements. A useful technical specification separates the checks.

Companies House continues to warn users that information on the register should not automatically be treated as verified or validated. Its powers and checking processes have expanded, and identity verification is being introduced, but register data still reflects information filed with Companies House. Companies House register Searching the register guidance

For businesses covered by the UK Money Laundering Regulations, customer due diligence involves identifying and verifying customers, beneficial owners and people acting on their behalf. Companies House data can support that process. It does not complete the process. HMRC customer due diligence guidance

Lesson one from a real data-matching project

In one UK data-mapping exercise, we built a small application that accepted a spreadsheet of business names, searched Companies House, collected the company number and SIC codes, mapped each SIC code to its description, retained the client's internal account reference and produced an Excel file for review.

The API responses were consistent. The matches were not.

Some source names did not exactly match the registered legal names. Trading names, abbreviations, punctuation, former names and businesses with similar names created ambiguity. In one reviewed example, the Companies House search result selected by the script was wrong, while a broader web search surfaced the intended business.

The initial assumption was:

The safer model became:

This is the most important design decision in a Companies House onboarding flow. Search results are candidates. The company number is the durable identifier.

A practical company-matching score

When the customer already knows the company number, request it and use it directly. Preserve it as a string because leading zeroes and letter prefixes matter. When a user enters a company name, show candidate records and ask them to select one. For spreadsheet imports or CRM enrichment, introduce a confidence score and a review queue.

This is the starting score we use when designing such systems:

Recommended routing:

These weights are a starting model. A production system should calibrate them against reviewed matches from its own customer base. Name normalisation should remove superficial differences while preserving meaningful words. Useful transformations include case folding, repeated-space removal, punctuation normalisation and careful treatment of common legal suffixes such as Limited and Ltd. Aggressive fuzzy matching can join two different businesses, so postcode and other corroborating details should carry substantial weight.

Lesson two from a scheduled Companies House sync

Another UK accounting platform we supported used a scheduled Companies House synchronisation job. During a production incident, company names disappeared and customer records were affected. The wider application recovered after the Companies House job was disabled.

This exposed a common integration risk: an external registry feed had become authoritative over the platform's operational customer record. A missing value, changed response, incorrect match or partial job should never erase information that the customer has already confirmed.

We now recommend separating the data into four records:

customer_company
    Operational record confirmed by the customer

registry_link
    Selected company number, match method and verification state

registry_snapshot
    Raw or mapped Companies House data with retrieval time and ETag

registry_change_event
    Detected change, review status and audit history

The scheduled job updates registry_snapshot. Business rules decide whether a detected difference updates the operational record, creates a review task or sends an alert.

1. A null API value cannot overwrite a confirmed customer value.
2. A changed company name becomes an event with previous and current values.
3. A failed batch can resume without repeating completed updates.
4. Every automated decision has an audit trail.
5. The Companies House integration can be paused without stopping the customer platform.

The four-stage onboarding architecture

1. Discover

Accept a company name or company number. A number should lead directly to the company profile endpoint. A name should call the company search endpoint and return a short candidate list.

Display enough information to distinguish similar companies:

• Legal name
• Company number
• Status
• Registered office locality and postcode
• Incorporation date
• Company type

Search should be debounced and performed by your server. Keep the API key away from browser code.

2. Resolve

Ask the customer to confirm the correct company. Save the company number, search term, selected candidate and confirmation time. Automated imports should store all serious candidates and the reasons behind the score. A reviewer should see why candidate A scored above candidate B.

An explainable match such as “legal name and postcode matched” is more useful than an unexplained confidence of 96 per cent.

3. Verify

Fetch the company profile, officers and PSCs after selection. Apply rules appropriate to the product and its regulatory exposure.

For a basic business account, this may involve:

• Active company status
• Customer confirmation of company number
• Business email verification
• Confirmation that the applicant has authority to act

For a regulated or higher-risk relationship, the workflow may also need:

• Identity verification for the applicant
• Beneficial-owner identification and verification
• Sanctions and PEP screening
• Nature and purpose of the relationship
• Source-of-funds or wealth checks where required
• Enhanced due diligence based on risk

The current UK Sanctions List is the UK Government's source for designated people, entities and ships. The former OFSI Consolidated List closed on 28 January 2026, so integrations should use the current source. UK Sanctions List

4. Monitor

Company status, officers, PSCs, filing events and insolvency information can change after onboarding.

Low-volume products can refresh selected records on a schedule. Larger datasets can start from a Companies House snapshot and consume the Streaming API to keep a local dataset current. The API pushes real-time changes through a long-running connection and supports company, filing, officer, PSC, charge and insolvency streams. Streaming API overview Streaming API reference

Streaming consumers need durable timepoint storage, idempotent event processing and reconnection backoff. Companies House permits a maximum of two concurrent streaming connections per account and advises clients to resume from the last processed timepoint after a disconnect. Streaming connection guidance

Identity verification changes in 2026

Companies House identity verification became a legal requirement on 18 November 2025, with a twelve-month transition period for existing directors and PSCs. New directors and PSCs entered the requirement from that date, while existing people must verify according to their applicable due dates. Identity verification guidance When verification is required

Officer and PSC API resources can now contain optional identity_verification_details. Depending on the record, these details can include the verification date, the name of an Authorised Corporate Service Provider and appointment verification dates. Officer resource PSC resource

A safe server-side implementation

The following TypeScript example shows a minimal server-side client:

const baseUrl = "https://api.company-information.service.gov.uk";

function companiesHouseAuth() {
  const apiKey = process.env.COMPANIES_HOUSE_API_KEY;

  if (!apiKey) {
    throw new Error("Companies House API key is missing");
  }

  return `Basic ${Buffer.from(`${apiKey}:`).toString("base64")}`;
}

async function companiesHouseGet<T>(path: string): Promise<T> {
  const response = await fetch(`${baseUrl}${path}`, {
    headers: {
      Authorization: companiesHouseAuth(),
      Accept: "application/json",
    },
    signal: AbortSignal.timeout(8000),
  });

  if (response.status === 429) {
    throw new Error("Companies House rate limit reached");
  }

  if (!response.ok) {
    throw new Error(`Companies House returned ${response.status}`);
  }

  return response.json() as Promise<T>;
}

export function searchCompanies(query: string) {
  const params = new URLSearchParams({ q: query, items_per_page: "10" });
  return companiesHouseGet(`/search/companies?${params}`);
}

export function getCompany(companyNumber: string) {
  return companiesHouseGet(`/company/${encodeURIComponent(companyNumber)}`);
}

A production version should add:

• Input-length and character validation
• Request correlation IDs
• Caching for repeated searches and profiles
• A queue for bulk enrichment
• Controlled retry with jitter
• A circuit breaker when error rates rise
• Structured logs without unnecessary personal data
• Metrics for 429, timeout, mismatch and manual-review rates

At the published limit, the theoretical average is two standard API requests per second. A bulk worker should operate below that rate so interactive searches retain capacity. Caching candidate searches for a short period and company profiles for longer reduces repeated traffic.

Companies House provides a sandbox running the same API versions as the live environment. Use it for response handling, failure paths and test data before connecting production workflows. Some services have sandbox limitations, so test critical reads against controlled live records as well. API testing guidance

Update rules that protect customer data

Each mapped field should have an explicit update policy.

The confirmed company number anchors the relationship. Future name searches should never silently relink the customer to another company.

Privacy and retention

Public availability does not remove UK GDPR responsibilities when officer or PSC information is stored and used in your own system. The ICO's data-minimisation principle requires organisations to identify the minimum personal data needed for a defined purpose. Storage limitation requires a retention period connected to that purpose. ICO data-minimisation guidance ICO storage-limitation guidance

Practical controls include:

• Store the company number and decision evidence required for the relationship.
• Avoid copying every officer and PSC field into the customer database.
• Record the source URL or endpoint, retrieval time and decision outcome.
• Set retention rules for rejected applicants and expired checks.
• Restrict access to identity and due-diligence records.
• Explain registry checks in the privacy notice.
• Keep an audit trail showing automated and human decisions.

Implementation checklist

Before releasing a Companies House onboarding flow, confirm that:

This article provides technical and operational guidance. Businesses with legal or regulatory obligations should have their onboarding and due-diligence policy reviewed by an appropriate UK compliance professional.