Monitoring architecture
Company Registry API Rate Limits: How to Plan Reliable Company Monitoring
A practical guide to company registry API rate limits, polling schedules, update feeds, backfill, retries, and source-backed monitoring across official business registers.
Short answer
Company registry API rate limits decide how fast you can ask an official register for data. Reliable company monitoring also depends on freshness, update feeds, result windows, retry behavior, backfill, deduplication, and whether each alert keeps a source trail for review.
Company registry API rate limits matter when you monitor a portfolio of companies after onboarding. A few manual lookups rarely create pressure. A recurring job that checks thousands of companies across several countries can hit limits, miss updates, or create noisy duplicate alerts if it is designed like a simple lookup tool.
This guide is for fintechs, KYB products, merchant-risk teams, supplier-risk teams, B2B platforms, and engineering teams deciding whether to build registry monitoring internally or use a company monitoring API.
It stays focused on official registry monitoring after onboarding: status changes, filings, directors, addresses, capital, liquidation, insolvency, bankruptcy, and similar source-backed company changes.
Why this topic matters now
Search results for this topic are fragmented. There are strong official pages for individual sources, generic API rate-limit explainers, and some developer notes about single registries. There is much less practical guidance on how rate limits, source freshness, update feeds, and backfill combine in a company-monitoring workflow.
That gap matters because official company registers do not behave the same way. Companies House publishes a request limit and returns 429 responses after the limit is exceeded. Companies House streaming offers long-running streams for several data types. PRH open data says its data is updated once per day. Brreg's Enhetsregisteret API exposes search, downloads, and update endpoints with result sizing rules. KVK publishes both monthly and per-second query limits for its Dutch API subscriptions.
A reliable monitoring system has to translate those source-specific rules into one operational promise: watch the right companies, detect meaningful changes, and preserve the official evidence.
What are company registry API rate limits?
Company registry API rate limits are request rules set by an official company register or data provider. They tell you how many calls your application can make in a window such as a second, five minutes, month, or another measured period.
Rate limits are not the same as company-monitoring coverage. A high limit does not mean the data is realtime. A low limit does not mean monitoring is impossible. The practical question is how many source calls are needed to resolve companies, check for updates, fetch details, store evidence, and recover safely when a job fails.
For a broader implementation view, read the company monitoring API guide. For risk-team context after onboarding, read the post-onboarding KYB monitoring guide.
Rate limits vs freshness vs result windows
The most common mistake is treating "API access" as one single constraint. In registry monitoring, three constraints matter at the same time.
Rate limits control request volume
A rate limit answers: "How many requests can we make before the source slows, rejects, or blocks us?" Companies House, for example, says clients can make up to 600 requests within five minutes, and that excess calls receive 429 responses until the window resets.
Freshness controls how soon a change appears
Freshness answers: "How soon can the source show the change we care about?" PRH says Finnish open-data records are updated once per day. That means polling the same PRH source every minute will not turn daily source data into minute-level monitoring.
Result windows control how you paginate
Result windows answer: "How much can we safely fetch from one endpoint before we need a different strategy?" Brreg's Enhetsregisteret documentation lists update endpoints and says update result size can be requested between 1 and 10,000, with 100 as the default.
A good monitoring plan respects all three. It does not just ask whether an API exists. It asks how source calls should be paced, how often the source updates, and what happens when a result set is larger than expected.
Official source examples
These examples show why company monitoring needs source-specific planning. They are not interchangeable lookup APIs.
| Source | Useful monitoring path | Planning constraint |
|---|---|---|
| Companies House | Search, company profile, filing history, document metadata, and streaming endpoints | Published API limit of 600 requests per five minutes; streaming still needs cursor recovery and deduplication |
| PRH / Finnish open data | YTJ company search and registered notifications for Finnish Trade Register records | Open data is updated once per day, so polling frequency should match source freshness |
| Brreg / Enhetsregisteret | Entity lookup, downloads, entity updates, role updates, and snapshot comparison | Update endpoints have size and pagination constraints; many alerts require refetching and diffing the latest record |
| KVK Netherlands | Paid API subscription with search and company-profile style workflows | KVK publishes subscription query limits and per-query pricing; plan for quotas before adding Dutch coverage |
Current Churnscan workflow coverage is focused on the United Kingdom, Finland, and Norway. Netherlands is useful as a planning example because it shows how paid quotas and query costs can change the architecture before a country is added.
How to estimate the call budget
A call budget is a plain-English estimate of how many source requests your monitoring workflow needs. It should cover onboarding, routine checks, backfill, detail fetches, and retries.
Start with this simple model:
- How many companies will be watched in each country?
- How many source requests are needed to resolve or confirm each company?
- How many requests are needed for each routine monitoring pass?
- How often does the source actually publish useful updates?
- How many additional requests are needed when a change is detected?
- How much backfill is required when a company is first added?
- What retry behavior is allowed after timeouts, 429 responses, or source downtime?
A UK-only monitor for 5,000 companies might need one filing history call per company for a routine pass, plus extra calls for profile refreshes, document metadata, officer checks, or detected changes. A Finland monitor should not use the same cadence if the open-data source is updated once per day. A Norway monitor may lean more on update feeds and entity snapshot comparison than on per-company filing history.
The point is not to calculate a universal number. The point is to keep the monitoring plan tied to the source's real shape instead of guessing from the word "API."
Where monitoring jobs break
Company monitoring jobs usually break in predictable places. Most failures come from bursts, retries, missing cursors, weak matching, or treating country-specific data as if every register emits the same event format.
Backfill creates a burst
When a customer uploads a large company list, the system may need to resolve names, confirm identifiers, fetch recent history, and create watches. If all of that happens at once, backfill can consume more requests than the normal daily monitoring job.
Retries become a second outage
A failed request should not trigger unlimited retries. If an API returns 429, the monitoring job should slow down and wait for the allowed window instead of retrying immediately across every watched company.
Streams still need recovery
Streaming can reduce repeated polling, but a long-running connection can still disconnect. The workflow needs a cursor or replay strategy so it can resume without missing changes or duplicating every event.
Raw updates are not always alerts
Some sources tell you that a record changed but not which business-review signal matters. The monitoring layer still needs to fetch the latest record, compare it with the stored baseline, classify the change, and attach source evidence.
A practical rate-aware monitoring workflow
A rate-aware monitoring workflow should be boring in the best way: paced, recoverable, and easy to verify.
- Store the official company identifier as soon as the match is confirmed.
- Keep country-specific source rules in the monitoring layer, not in a reviewer checklist.
- Separate onboarding backfill from routine monitoring jobs.
- Use update feeds or streams where they exist, but keep a fallback recovery path.
- Pace requests below the published limit instead of running at the edge of the quota.
- Treat 429 responses, timeouts, and source errors as scheduling events, not as reasons to retry everything immediately.
- Compare refreshed records with stored baselines when the source does not provide explicit event labels.
- Deduplicate signals before they reach user feeds or review queues.
- Attach the source, company identifier, event date or update time, detected date, and evidence URL.
This is the difference between "we call the registry API" and "we run company monitoring." The second one has operational guardrails.
Questions to ask before building
Use these questions when deciding whether to build registry monitoring internally or use a company monitoring API.
- Which countries are needed now, and which are planned later?
- Does each source provide explicit events, an update feed, a stream, a daily dataset, or only a current snapshot?
- What is the published request limit, quota, cost, or result window for each source?
- How often does the source publish new data that is useful for monitoring?
- What company identifier should be stored to avoid repeated fuzzy matching?
- How will the system recover from missed windows, disconnects, partial failures, and 429 responses?
- Which detected changes become review alerts, and which should stay as low-priority record updates?
- What source evidence will a reviewer need before taking action?
How Churnscan fits
Churnscan monitors official company changes after onboarding. The product flow starts with a known company list or API request, resolves companies to official records, creates watches, polls official sources, normalizes useful changes, and returns source-backed signals.
Churnscan is not a full KYB, AML, sanctions, credit-scoring, UBO, prospecting, or sales-enrichment product. It is a narrow monitoring layer for official company registry changes after a company is already known.
For source-specific examples, read the Companies House monitoring guide, the Finnish company register monitoring guide, and the Norwegian company register monitoring guide.
FAQ
What are company registry API rate limits?
Company registry API rate limits are rules that restrict how many requests an application can make to an official company register API within a defined period.
Do rate limits tell you how fresh registry data is?
No. Rate limits control request volume. Freshness depends on the source's own update model, such as realtime streams, update feeds, daily open-data refreshes, or slower publication cycles.
How do you monitor thousands of companies without hitting limits?
Use stable official identifiers, store cursors and baselines, pace requests, separate backfill from routine polling, retry carefully after 429 responses, and prioritize high-risk signal sources first.
Is streaming better than polling for company monitoring?
Streaming can reduce repeated polling when a reliable stream exists, but it still needs recovery logic, deduplication, source evidence, and matching back to the companies you actually watch.
What should a company monitoring API handle for me?
A monitoring API should handle company resolution, rate-aware polling or streaming, source-specific freshness rules, deduplication, backfill, alert classification, and evidence links.
Sources and further reading
Monitor company changes without rebuilding each source
Use Churnscan to upload a company list or connect by API, confirm official matches, create watches, and review source-backed registry changes across supported countries.