Company monitoring API
Company Monitoring API: How to Track Official Registry Changes Without Building It Yourself
A company monitoring API helps teams track official registry changes for known companies without building every country integration, polling job, matching flow, and evidence trail internally.
Short answer
A company monitoring API tracks official registry changes for companies you already care about. Instead of manually checking business registers or building country-by-country polling systems, teams can resolve companies, create watches, and receive source-backed alerts when official records change.
This is useful for fintechs, KYB products, merchant-risk teams, B2B platforms, lenders, and supplier-risk teams that already have a known list of businesses after onboarding.
The goal is narrow: monitor official company changes such as status, directors, address, capital, filings, liquidation, insolvency, and bankruptcy. It is not the same as a full company database, sales enrichment tool, credit bureau, AML suite, or sanctions-screening product.
What is a company monitoring API?
A company monitoring API is a software interface that lets a product or risk team track official changes to registered companies over time.
The basic workflow is:
- Send a company name, country, official company ID, or portfolio file.
- Resolve the company to an official registry record.
- Confirm the right company when the match is ambiguous.
- Create a watch for the confirmed company.
- Poll or ingest official registry sources.
- Normalize changes into readable signals.
- Return matched alerts with source evidence.
The API layer matters because raw registry data is rarely shaped around your product workflow. Registry sources usually expose records, filings, notices, or updates. A monitoring API turns those raw inputs into alerts your team can use.
What official registry changes can be monitored?
The best-fit signals for official registry monitoring are legal, status, and filing changes.
Common company monitoring API signal types include:
- Company status changes
- Liquidation, insolvency, bankruptcy, dissolution, or forced closure
- Director, officer, board, or signing-right changes
- Registered address and postal address changes
- Company name and identity changes
- Capital changes and share allotments
- Mergers, demergers, and legal structure changes
- New official filings, notices, and registered entries
These signals are especially useful because they can usually be linked back to an official registry record, filing, notice, or source URL.
Official registry monitoring is weaker for signals that do not normally live in company registers, such as job openings, customer wins, technology changes, awards, website edits, adverse media, broad fraud signals, and sales-prospecting data. Those usually require other sources.
Why raw registry APIs are not always enough
Raw registry APIs are valuable, but they are not the same as a finished monitoring workflow.
For example, Companies House provides public API access for company profiles, company search, officers, charges, filing history, insolvency, and related resources. It also documents a streaming API for real-time data changes and a published rate limit of 600 requests per five-minute period per application.
Those building blocks are strong, but a product team still has to decide how to search, match, poll, store, deduplicate, classify, and deliver changes. The same pattern appears across countries: the official source may expose useful data, while the monitoring workflow still has to be built.
Norway's Brønnøysund Register Centre provides APIs, downloadable datasets, and update feeds for organisation data. Finland's PRH provides public Trade Register notices and open data interfaces. Each source has its own identifiers, freshness model, language, schema, event style, and limits.
That is the hidden work: a company monitoring API is not just an HTTP wrapper around one registry. It is a workflow layer across registries.
The work behind a reliable monitoring workflow
A reliable monitoring workflow has several pieces. Missing any one of them can turn official data into noisy, stale, or hard-to-review alerts.
Resolve the right company
Company names are often ambiguous. A name-only search can return multiple companies with similar names, old companies, branches, subsidiaries, or dissolved entities.
A useful API should resolve a company to a canonical official record. It should store the country, official company ID, company name, source, status, and source URL.
Confirm ambiguous matches
Automatic matching is helpful when confidence is high. It is risky when the input is weak.
If a user uploads "Acme Ltd" with only a country, the system may need to show candidates and ask for confirmation before creating a watch. That extra confirmation step prevents teams from monitoring the wrong legal entity.
Create a watch
A watch is the product object that says: "track this specific company from this official source."
The watch should not depend only on the original company name. It should point to the resolved official record, because the name itself may change later.
Poll official sources
Some sources are best monitored by polling company-level endpoints. Others provide update feeds, daily notices, downloadable files, or streams.
The monitoring layer has to choose the right source strategy by country. A simple one-size-fits-all polling loop is usually not enough once coverage expands beyond a single register.
Normalize registry changes
Official sources use different forms, codes, languages, and event names. A reviewer does not want to interpret every raw registry code.
Normalization turns raw source events into shared signal types such as company_status_change, governance_change, address_or_identity_change, capital_change, or insolvency_or_liquidation.
Deduplicate signals
Registry data can produce duplicate-looking events. A filing may appear in a stream and in a later polling run. A source event may be fetched again during backfill. Multiple users may also monitor the same company.
A good monitoring system deduplicates global source signals, then matches the relevant signal into each user's feed.
Attach source evidence
Every alert should show where it came from.
Useful evidence includes source name, source URL, filing or notice reference, detected date, published date when available, source company ID, and the raw source record when it can be retained.
This evidence is what makes the alert reviewable. Without it, the API is just returning a claim.
Deliver matched alerts
The final step is delivery. A monitoring API should let teams list matched signals, filter them by watched company or signal type, and pull them into internal review workflows.
For many teams, the first version does not need complex scoring. It needs a clear feed of official changes that humans or downstream systems can inspect.
Build vs buy: when to use a monitoring API
Building registry monitoring internally can make sense when one country and one signal type are enough. It becomes harder when the workflow needs multiple countries, ambiguous matching, backfill, deduplication, source evidence, and operational monitoring.
| Question | Build internally | Use a company monitoring API |
|---|---|---|
| You only need one registry | Often reasonable | Still useful if speed matters |
| You need multiple countries | Requires separate source work per country | Better fit |
| You need name matching and confirmation | Must be designed and maintained | Should be built into the workflow |
| You need source-backed alert evidence | Must store source references carefully | Should be included with each signal |
| You need backfill for existing portfolios | Requires date-window and replay logic | Should be part of watch creation |
| You need a product team to move quickly | Slower if registry work is not core | Better fit |
The practical question is not "Can we call the registry API?" It is "Do we want to own this monitoring workflow across every source we need?"
What to look for in a company monitoring API
Use these checks when comparing company monitoring APIs.
Country coverage
Look for the countries you need today and the source strategy behind each one. Do not treat a long country list as proof of equivalent coverage.
For official registry monitoring, coverage should explain which countries are live, which sources are used, and which signal groups are strong or partial.
Signal types
The API should make clear which changes it monitors. Useful starting groups are risk changes and legal entity changes.
- Risk changes: insolvency, liquidation, bankruptcy, dissolution, and company status changes.
- Legal entity changes: directors, officers, address, company name, capital, filings, mergers, and demergers.
Avoid vague promises such as "all company events" unless the provider explains the source and evidence model.
Source URLs and evidence
An alert should include enough evidence for review. At minimum, expect a source name, source URL or source reference, company identifier, detected date, signal type, and a readable summary.
Backfill
Backfill matters when you start from an existing company list. It lets you ask whether anything important happened recently, instead of waiting for the next future change.
API-first workflow
A monitoring API should be easy to integrate into product flows. The important endpoints are usually company resolution, watch creation, polling or ingestion status, and signal listing.
CSV onboarding
Many teams begin with a portfolio file, not a finished API integration. CSV onboarding is useful because it lets a risk or operations team test coverage, matching, and alert quality before deeper integration.
Example company monitoring API workflow
Here is a practical workflow for a product or risk team.
- Export a list of approved companies from your product, CRM, underwriting system, supplier tool, or merchant platform.
- Send each company to the API with country and any known official company ID.
- Resolve each company against the official registry.
- Review any ambiguous matches before creating watches.
- Create watches for confirmed companies and choose the signal groups to monitor.
- Run backfill to catch recent changes.
- Pull matched alerts into a review queue.
- Store the source evidence with the internal case or customer record.
That workflow is intentionally simple. The value is not in adding another large compliance platform. The value is keeping known company records current with official changes after onboarding.
Company monitoring API vs company database
A company monitoring API and a company database solve different problems.
| Category | Company monitoring API | Company database |
|---|---|---|
| Primary job | Track changes over time | Look up company profiles |
| Best starting point | Known companies you already care about | Broad search or enrichment |
| Output | Alerts and source-backed signals | Profile fields and firmographic data |
| Timing | Ongoing after onboarding | Often point-in-time |
| Evidence need | High, because alerts trigger review | Varies by use case |
| Churnscan focus | Official registry changes after onboarding | Not a broad enrichment database |
If your team needs broad prospecting, enrichment, or sales data, a company database may be the better fit. If your team needs to know when approved companies change, a monitoring API is the narrower tool.
How Churnscan supports company monitoring
Churnscan provides a lean API and console for monitoring official company changes after onboarding.
The workflow is:
- Start from a company list or API request.
- Resolve the company against official sources.
- Confirm the match when needed.
- Create a watch.
- Attach recent backfill.
- Poll official sources.
- Normalize registry changes into source-backed signals.
- Read matched alerts from the API or console.
Churnscan is built for teams that already know which companies they need to monitor: fintechs, KYB products, B2B platforms, merchant-risk teams, lenders, and supplier or customer-risk teams.
Current workflow coverage includes the United Kingdom, Finland, and Norway. The focus is official registry changes, not prospecting, credit scoring, AML screening, sanctions screening, or broad enrichment.
FAQ
What is a company monitoring API?
A company monitoring API tracks official registry changes for companies over time. It lets a team resolve companies, create watches, monitor registry sources, and receive alerts when official records change.
What company changes can an API monitor?
The strongest official registry signals are status changes, liquidation, insolvency, bankruptcy, dissolution, director and officer changes, address changes, capital changes, legal structure changes, and new filings or notices.
Do I still need official company IDs?
Official company IDs are the best input when available because they reduce ambiguity. A useful monitoring API can also start from company name and country, but it should ask for confirmation when the match is uncertain.
Can I monitor companies from a CSV file?
Yes. A practical workflow can start from a CSV company list, resolve each row to an official record, ask the user to confirm uncertain matches, and then create watches for the confirmed companies.
Is a company monitoring API the same as a company database?
No. A company database is usually built for lookup, profile data, or enrichment. A company monitoring API is built to track changes over time and return alerts with evidence.
Sources and further reading
Monitor official company changes by API.
Use Churnscan to start from a company list, resolve official records, create watches, and review source-backed alerts.