Live Registry API vs. Stored Registry Data: The Architecture That Actually Works at Scale

If you have ever sat in a vendor meeting and heard the phrase "we integrate directly with government registries in real time," you have heard a marketing line, not a technical architecture.

The instinct behind it is correct. Registry-sourced data is the gold standard for KYB, AML, and supplier verification. Regulators want it. Auditors expect it. Buyers in financial services and procurement now ask for source attribution and timestamps on every record. There is no serious challenger to government registries as the system of record for legal entities.

The implementation, however, is where most vendors quietly fall apart. Building a verification or enrichment product on top of live registry calls — making an HTTP request to Companies House, the SAT, or the Registro Mercantil every time someone needs a record — is operationally unworkable for anyone running at enterprise scale. The registries themselves are the bottleneck.

This article breaks down exactly why, and what the practical alternative looks like.

The five problems with live registry integration

Every vendor evaluating their data architecture eventually hits the same five constraints. They are structural, not solvable by better engineering on the buyer's side.

Problem 01 in detail: the registry API map is mostly empty

The simplest way to understand the live-integration problem is to look at a map of where APIs actually exist. We maintain a complete jurisdiction-by-jurisdiction reference here: Business Registry API Access by Country: The Global 2026 Map. The picture outside Europe is harsher.

Reading that chart, a few realities become uncomfortable:

• The United States has no federal company registry. Each of the 50 states maintains its own Secretary of State database. Independent developers have documented that most of these — Texas, New York, Florida, and others — have no public API. California launched an official SOS developer portal in the past year, the first major state to do so. The rest are ASP.NET forms with ViewState, CAPTCHA, and silent rate limits.
• Canada has 14 separate registries — one federal and 13 provincial/territorial — each with its own access rules. See our deep-dive on Canadian business registry search across federal and provincial systems for the full breakdown.
• Across the Middle East, large APAC markets, and most of LATAM, business registry data is published through portals that require manual lookups — sometimes in person, often in the local language only, and frequently behind paid extracts.

If your verification workflow needs to cover companies in 100+ countries, the live-API approach has a hard ceiling. There are 25 jurisdictions globally where an official registry API exists. Beyond country number 25, there is nothing to integrate against.

And of those 25, only 19 are free

"Has an API" and "the data through that API is free" are two different things. Of the 25 jurisdictions worldwide with an official registry API, only 19 publish company data without per-call charges. The other six — Spain, Italy, Netherlands, Austria, Saudi Arabia, and South Africa — operate paid-per-record models. The API is the access mechanism; the data behind it is metered.

One caveat applies across the board: "free" almost always means free access to structured company records — name, number, status, type, registered address, directors, submission history. Retrieval of document images — annual returns, accounts, memoranda, certified extracts — is typically paid, even in the most open jurisdictions. The UK Companies House charges nothing for the core record but applies fees for certified documents. Ireland's CRO Open Data Portal is free for company records but pay-per-call for document retrieval. Switzerland's Zefix is free for the register extract but CHF 50 for the certified version. The free-vs-paid split below tracks the structured-record API.

25 jurisdictions out of 198 with an official registry API · 173 have no API at all · Verified May 2026

The paid registries are not edge cases. Spain, Italy, and the Netherlands together represent some of the largest economies in continental Europe. The Spanish nota simple costs €9.02 + VAT per company extract. Italian InfoCamere charges fluctuate by document type. Dutch KVK is tiered. Saudi Arabia's Wathq is credentials-gated and billed.

The per-record cost is the visible part of the problem. The harder part — the part that turns a paid API from a unit-cost question into a project-cost question — is the workflow the buyer has to build around it: pre-funded credit balances with each registrar, per-call cost attribution, spend guardrails, internal pricing logic, six separate VAT registrations, and per-record receipt storage. That work is the substance of Problem 05 below, where it sits alongside every other piece of per-registry plumbing the buyer has to ship before the integration is usable.

Problem 02 in detail: latency and rate limits

Even where APIs exist, the throughput is rarely engineered for enterprise volumes. Companies House — widely regarded as the best-built registry API globally — applies a hard limit:

That last figure is the one nobody warns you about. Building one full integration — schema mapping, error handling, retry logic, monitoring, compliance review — takes a cross-functional team somewhere between one and three months. Multiply that across the 100+ registries you would need for full global coverage and you are looking at years of engineering effort just to keep the connections alive, before you write a single line of product code.

And response times in the wild are nothing like the cached-CDN speeds developers expect from a modern SaaS API. National registries frequently return profiles in 2–8 seconds, and that excludes downstream calls for filings, officers, and ownership documents. For a real-time onboarding flow, that latency budget is unworkable.

Problem 03 in detail: uptime is not their job

This is the one that gets glossed over in vendor pitches. Government registries are not run as commercial services. They have no enterprise SLA. They have planned maintenance windows that are announced in legalese on websites that few engineers read. Schema changes ship without deprecation notices. Authentication can be tightened overnight in response to scraping incidents elsewhere.

The UK Companies House developer forum has open threads with engineers asking "is the API down?" on a recurring basis. The UK is, again, the best-case scenario. In jurisdictions where the registry runs on infrastructure shared with broader government services, downtime windows of hours or days happen routinely — particularly around fiscal-year changes, regulatory transitions, or tax filing deadlines when registries are flooded.

If your customer onboarding, supplier verification, or payment authorisation flow depends on a live response from a foreign government registry, you are inheriting their uptime profile. That is not a risk an enterprise compliance team can absorb.

Problem 04 in detail: cross-jurisdiction joins are impossible live

This is the biggest one, and it is rarely discussed because it is technical rather than commercial. Live integration cannot answer the questions that matter most for compliance.

Take a real example. You are onboarding a UK-incorporated supplier. Its shareholder is a Dutch holding company. The Dutch holding company is owned by a Cayman Islands entity. The Cayman entity has two directors who also serve on the boards of three other entities, one in Singapore and two in the BVI. The ultimate beneficial owner is a natural person resident in Switzerland.

To resolve that chain live, you would need to:

1. Call the UK API to retrieve the supplier's shareholders.
2. Parse the Dutch shareholder name — which the UK record stores as free text, not a foreign key.
3. Search the Dutch KVK for the holding company, hoping the name matches exactly.
4. Retrieve the Dutch shareholder data — which is frequently stored only in filed PDFs, not in the API.
5. OCR or manually parse the PDFs to find the Cayman entity name.
6. Query the Cayman registry (which has no API and requires paid manual lookup).
7. Match the directors to entities in three further jurisdictions.
8. Cross-reference Switzerland's commercial register (Zefix) for the UBO declaration.

That is eight sequential operations across five jurisdictions, four different schemas, two languages, one OCR step, and at least one manual retrieval. There is no way to make that happen during a customer's onboarding session. It has to be pre-computed — meaning the data has to be stored, joined, and indexed in advance.

Problem 05 in detail: every registry is a separate integration project

This is the problem buyers underestimate the most. The other four problems describe what the registry world looks like from outside. Problem 05 describes what it looks like once you are inside it, trying to do the work.

An API existing is not a deliverable. A working integration is. The distance between the two is where teams quietly lose six to twelve months of engineering time per registry — and where the operating cost of running a live-API approach keeps growing long after launch.

Here is what has to be built, per registry, for every jurisdiction in scope:

1. A bespoke authentication layer

UK Companies House uses an API key per application. France's INPI requires an account, OAuth flow, and per-environment credentials. Switzerland's Zefix issues credentials by email request. Sweden's Bolagsverket runs OAuth2 with separate scopes per dataset. Saudi Arabia's Wathq runs on issued service accounts. The Netherlands' KVK requires a contract, a local entity, and customer onboarding. Estonia uses national eID. Spain's CORPME requires a commercial conversation with api@corpme.es and custom client development.

There is no shared standard. Each integration starts with reading a different authentication document and building the equivalent of a small SDK that nobody else can reuse.

2. A payment and billing workflow — for the six paid registries

For Spain, Italy, Netherlands, Austria, Saudi Arabia, and South Africa, the API call is only half the workflow. Each request triggers a charge against a pre-funded balance or invoiced account. The team has to build:

• A pre-funding mechanism with each registrar's finance department, including treasury approvals to keep balances topped up
• Per-call cost attribution so each registry charge ties back to the customer, business unit, or onboarding case that triggered it
• Spend guardrails so a buggy retry loop or a sudden volume spike does not generate a five-figure surprise invoice
• Internal pricing logic deciding whether to pass per-call costs through to your end customer, absorb them, or cap them per onboarding
• VAT handling per registrar's jurisdiction — six separate VAT registrations and reclaim positions to maintain
• Receipt storage, because each invoice is a tax document that has to be retrievable for years

None of that is the company-verification product. It is a registry billing engine — a side project that has to ship before the actual product can launch.

3. An error and retry layer that knows each registry's failure modes

UK Companies House throws a 429 when its 600-requests-per-five-minutes ceiling is hit, with a Retry-After header that the team has to honour. France's INPI returns 502s during nightly maintenance windows. Germany's Handelsregister (when scraped, since there is no official API) silently inserts CAPTCHAs after a few hundred sequential requests. Italy's InfoCamere periodically returns successful HTTP 200s with empty payloads when their backend is under load. Each registry has its own catalogue of half-broken states, and the team has to build per-registry handlers for all of them — plus the dashboards and alerting that make those failures visible to support before customers notice.

4. A per-registry data normalisation layer

UK Companies House returns directors with separate first-name, surname, and middle-name fields. France's Sirene returns the legal representative as a single concatenated string with the role appended in French. Estonia returns a normalised ID code. Spain returns names in title case with conjunctions ("y", "de la") that have to be handled. Czechia returns Cyrillic transliterations of foreign directors. The team has to design a target schema and write twenty-five separate adapters that map each registry's payload into it — and maintain those adapters every time a registry changes its response format, which they do without notice.

5. A complete audit trail per call

Compliance frameworks — AMLD6, the EU AML Single Rulebook, FinCEN's CDD rule, FCA SYSC — require that the verification decision be reproducible. The team has to store, per call: the request payload, the response payload, the timestamp, the data source, the source-registry record version, the user or system that initiated the call, and the registry's official receipt. Per registry. Forever. This is non-negotiable for regulated buyers and it is a substantial storage and retrieval problem that does not appear in any API documentation.

6. Ongoing maintenance — forever

None of the above is one-time work. Every registry updates its schema, rotates its credentials, deprecates endpoints, and changes its rate limits on its own schedule. A team running a live-API approach across 25 jurisdictions is operating 25 separate ongoing integrations, each with its own changelog to monitor, its own forum to follow, and its own incident response process. The marginal cost of "we should also cover Singapore" is not a quick win — it is another permanent engineering surface the team has to keep alive.

What "stored and refreshed" actually looks like

The alternative to live integration is not what most engineers picture when they hear the word "database." A modern registry data infrastructure is closer to a streaming ETL pipeline with a data warehouse behind it, plus an enrichment layer, plus a delivery layer.

Here is what the architecture has to handle to be worth the investment:

1. Daily ingestion from source

Each registry has its own update cadence and delivery format. UK Companies House publishes daily bulk products and a streaming API. Ireland's CRO publishes daily open data. Singapore's ACRA, Belgium's CBE, and New Zealand's Companies Office publish monthly. Some registries publish only on request, in CSV, in the local language.

The job is to pull from each in their native format, on their native schedule, and standardise the output every day. Global Database runs this ingestion against 400+ registries continuously. When updates arrive, they are processed automatically the same day.

2. OCR and digitisation of financial filings

This is the part most data vendors skip. A huge proportion of registry filings — particularly financial statements in continental Europe, Asia, and Latin America — are submitted as scanned PDFs, not structured data. The UK's iXBRL financials are the exception, not the rule.

For these to be useful in a database, they have to be OCR-processed, then parsed against the local accounting taxonomy, then mapped to a standard schema so a Spanish balance sheet looks the same shape as a German one. We do this automatically on every new filing. If the entity already exists in the database, the record is updated. If it does not, a new entity is created.

3. Enrichment, not just ingestion

Raw registry data is the floor, not the ceiling. A registered name, number, and address tell you the entity exists. They do not tell you whether it is risky to engage with, who is really behind it, or what it owes whom. Every record in Global Database is enriched at ingest with corporate linkage mapping, ownership graphs, credit scoring, sanctions and PEP screening, financial ratios, industry classification, employee estimates, and decision-maker contacts — built from the same registry data, processed in advance, available as a single response.

4. Multi-region infrastructure for uptime

If the goal is to fix the uptime problem registries impose, your own infrastructure has to be more reliable than theirs. Global Database runs on Google Cloud and on dedicated Hetzner infrastructure in Germany, with failover between the two. Customer-facing APIs are decoupled from registry ingestion entirely, so a national registry being down has no effect on customer query response times.

The honest comparison

This is what the two approaches look like side-by-side, with no marketing varnish.

"But isn't live data fresher?"

This is the natural objection, and it deserves a direct answer. In theory, a live API call returns the freshest possible state of the registry. In practice, here is what actually happens to "freshness" once registries are in the loop:

• Registries themselves lag. A director appointment in many EU countries is filed within weeks, not days. A live API call retrieves whatever the registry has, which is rarely what happened yesterday.
• Most use cases do not need real-time. Onboarding, supplier verification, periodic KYB refresh, sanctions screening — none of these require sub-day latency. They require known freshness with a timestamp on the record, which is exactly what stored-and-refreshed delivers.
• Where event-driven freshness matters, it is solved by webhooks or change feeds — not by live calls. Global Database emits update events when monitored entities change. You react to the event; you do not poll the registry hoping to catch it.

The "freshness" argument for live integration is almost always a theoretical advantage that does not survive contact with a real production workload.

Where stored registry data still has to be done well

Storing the data is not the end of the problem. It is the start of a different one. A stored dataset is only as good as:

• Refresh cadence. Daily is the minimum acceptable standard for serious KYB use. Anything less risks the kind of stale-data failure the FCA has fined firms for. We refresh daily from source.
• Source attribution. Every field must carry the registry it came from and the date it was last verified. Regulators want to see provenance, not just data. Every Global Database record carries this.
• Entity matching. When new data arrives, you must correctly resolve it to existing entities, or create new ones cleanly. Get this wrong and you fragment ownership chains. Get it right and you build them automatically.
• Schema standardisation. A Spanish balance sheet and a German one look nothing alike on paper. They must look identical in your API response. This is real engineering work, not a setting.
• Delivery flexibility. Some teams want REST API. Some want bulk files. Some want webhooks. Some want all three. A serious provider supports all three.

The decision, plainly

If you are running a single-country product in the UK or Ireland with low volume, building directly against the registry API is a defensible choice. You will manage rate limits, absorb the occasional outage, and live with the latency. It can work.

For anything broader than that — multi-country coverage, enterprise SLA requirements, UBO and corporate-linkage workflows, or compliance audits that demand source-attributed records across hundreds of jurisdictions — live integration is not a viable architecture. The registries themselves prevent it.

The model that works is the one this article has been describing: registry data ingested directly from source, refreshed daily, OCR-processed where needed, enriched, joined across borders, and delivered through whichever channel fits your workflow. That is what Global Database is.