SEC EDGAR Filing Monitor

Durable monitor for new SEC filings — 10-K/10-Q annual/quarterly reports, 8-K material events, Form 4 insider trades, and more — on a watchlist of public companies, via the official, free SEC EDGAR Submissions API.

Why

Investors, analysts, and compliance teams want to know the moment a tracked company files something material (an 8-K especially — material events are time-sensitive). 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 contact email (SEC requires a descriptive User-Agent identifying the requester on every request — fair-use policy, not a secret, never shared elsewhere).
2. Each watch is one company you track by its SEC Central Index Key (cik).
3. Every run fetches the company's most recent filings (EDGAR returns newest first) and diffs them against a durable checkpoint of accession numbers already seen for that watch.
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",
  "userAgentContact": "you@example.com",
  "watches": [
    { "watchId": "apple", "cik": "320193" },
    { "watchId": "microsoft", "cik": "789019" }
  ],
  "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 guarantee: at-most-once (not exactly-once)

The right to write a row and to charge for it is granted by a single atomic primitive — one addRequest(uniqueKey) into a dedicated, named claim-journal Request Queue (<prefix>-<monitorId>-claims). Exactly one run ever wins that key. Claim requests are never deleted and never handled: the queue is a permanent journal of irreversible attempts, not a work list.

What this buys you, stated honestly:

• You will never be charged twice for the same filing. That is the guarantee.
• It is not exactly-once. If a run wins the claim and then dies before the row reaches the dataset (or before the charge completes), that filing is lost: it closes as dataset_unknown / charge_unknown and is never re-delivered. We deliberately prefer losing a delivery over double-charging you.
• Boundary of the guarantee: it holds for as long as the named claim-journal queue exists. Anyone with account access can delete or re-create that queue through the Apify Console/API; a fresh journal starts empty, and previously delivered filings could then be delivered and billed again. That is an inherent limit of any durable storage, not a defect of the protocol.
• Migration boundary: the guarantee applies from the build that introduced the claim gate onward. Older builds of this actor must not keep running against the same monitorId — they predate the journal and would not see the claims it holds.
• coverage.claimJournalSize reports the journal's size each run (best-effort; null if the queue's metadata could not be read, and the value lags by a few seconds because Apify's totalRequestCount is eventually consistent). Use it to watch growth, not to make decisions.

One-time storage rename in the claim-gate build

Named storages used to be derived from the full actor name (sec-edgar-filing-monitor, 24 characters). With a 40-character monitorId that produced a 65-character storage name — over Apify's 63-character limit, so long monitorIds could not work at all. They are now derived from a short prefix (sec-edgar), which keeps every name — including the new -claims queue — inside the limit. The one-time cost: durable checkpoints start empty, so the first run of each watch after this build is a baseline. A baseline delivers no rows and charges nothing, so this cannot cause double billing; you only lose one delta window.

Honest limits

• Each check fetches the company's recent filings feed (up to 1,000 most recent, EDGAR's own cap) — new filings appear at the top, sufficient for monitoring.
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced accession number can be re-billed — only matters for extremely high-filing-volume companies.
• We don't invent data: if the API response shape changes, or a watch's cik is wrong, the run reports it honestly instead of silently returning zero results.

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