UK Companies House Filing Monitor

Durable monitor for new filings — annual accounts, confirmation statements, charges/mortgages, officer appointments/resignations, insolvency notices, name changes — on a watchlist of specific UK companies, via the official, free Companies House "filing history" API.

Why

Credit-risk, compliance, and competitive-intelligence teams need to know the moment a tracked company files something material (a new charge often signals financing or distress; an insolvency filing is time-critical; a director change matters for KYC). Existing scrapers on Apify only do a one-off pull; none durably track what's already been seen and pay only for genuinely new filings.

How it works

1. You provide your own free Companies House API key (register instantly at developer.company-information.service.gov.uk — no cost, no approval wait). We never store it beyond the run.
2. Each watch is one company you track by its companyNumber.
3. Every run fetches the most recent page of that company's filing history (newest first — the documented Companies House ordering) and diffs it against a durable checkpoint of transaction IDs already seen.
4. Genuinely new filings are pushed to the dataset and billed once each (new-filing-detected); checking a watch with nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "my-watchlist",
  "chApiKey": "your-companies-house-api-key",
  "watches": [
    { "watchId": "competitor-a", "companyNumber": "12345678" },
    { "watchId": "portfolio-co-b", "companyNumber": "87654321" }
  ],
  "notifyOn": "new_alerts",
  "webhookUrl": "https://example.com/webhook"
}

Add more watches later under the same monitorId — each watch keeps its own independent history.

Billing

Pay-per-event: new-filing-detected — charged only for a filing genuinely new since the previous check of that watch. The first check of a new watch establishes a baseline (no charge). Failed/blocked checks are never charged.

Delivery and charging guarantee: at-most-once

For a single detected filing, the dataset write and the pay-per-event charge each happen at most once — never twice. This is not "exactly-once", and we do not claim it is: the right to perform an irreversible action (dataset write + charge) is granted by Apify's only atomic primitive, RequestQueue.addRequest(uniqueKey), in a separate named journal queue <prefix>-<monitorId>-claims. Apify's Key-Value Store has no CAS, no conditional write and no ETag, so a KV-based state machine cannot guarantee it and is kept for diagnostics only.

The trade-off is deliberate: if a run crashes after taking the claim, that event may be lost (it is closed as dataset_unknown / charge_unknown and is never re-delivered) — but you are never charged for it twice. "We never overcharge" is worth more than "we never miss a row".

Boundaries of the guarantee, stated honestly:

• it holds as long as the named claims queue exists. Anyone with account access can delete or recreate it from the Console/API, which starts the journal from scratch — an unavoidable boundary of any durable storage, not a defect of the protocol;
• it applies from the build that introduced the claim gate onward. Runs from older builds against the same monitorId are not covered, and old builds must not keep running on it;
• seenIds eviction (below) is a separate, independent source of possible re-billing.

Honest limits

• Each check fetches only the MOST RECENT page of filing history (up to 100 records), not the company's entire history — sufficient for monitoring, since new filings appear at the top. coverage.windowFullCount flags when a company has more filings than fit in that page (informational, not an error).
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced transaction ID can be re-billed — this only matters for companies with an unusually high filing rate.
• We don't invent data: if the API response shape changes, or a watch's companyNumber is wrong / the API key is invalid, the run reports it honestly instead of silently returning zero results.

Author: OmniCoder (https://t.me/OmniCoder)