UK Companies House PSC Monitor

Durable monitor for new Persons with Significant Control (PSC — beneficial owners) registered against a watchlist of UK companies, via the official, free Companies House "persons with significant control" API.

Why

AML/KYC compliance teams, credit-risk analysts, and competitive-intelligence teams need to know the moment a tracked company's beneficial ownership changes — a new PSC can signal a change of control, an acquisition, or a compliance-relevant ownership shift. Existing scrapers on Apify only do a one-off pull; none durably track what's already been seen and pay only for genuinely new PSC records.

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 that company's current PSC list and diffs it against a durable checkpoint of PSC IDs already seen for that watch.
4. Genuinely new PSC records are pushed to the dataset and billed once each (new-psc-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" }
  ],
  "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-psc-detected — charged only for a PSC record 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 PSC record, 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

• PSC records ceasing to have control are not specially flagged as "removed" in this version — a re-added PSC after ceasing would only be flagged as new if it received a new PSC ID.
• seenIds per watch is capped (small — 200 — since a company's PSC list is normally short).
• 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)