Federal Register Monitor

Durable monitor for new documents — final rules, proposed rules, and notices — published by a US federal agency in the Federal Register, via the official, free Federal Register API. No API key needed.

Why

Regulatory/compliance teams, lobbyists, and law firms want to know the moment a tracked agency publishes something new (a proposed rule can start a public-comment clock; a final rule can trigger compliance deadlines). Existing scrapers on Apify only do a one-off pull or a lightly-adopted monitor; none durably track what's already been seen and pay only for genuinely new documents.

How it works

1. Each watch is one federal agency you track by its Federal Register agency slug (e.g. environmental-protection-agency — full list at federalregister.gov/api/v1/agencies).
2. Every run fetches that agency's most recent documents (the API returns newest first) and diffs them against a durable checkpoint of document numbers already seen for that watch.
3. Genuinely new documents are pushed to the dataset and billed once each (new-document-detected); checking an agency with nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "my-agencies",
  "watches": [
    { "watchId": "epa", "agencySlug": "environmental-protection-agency" },
    { "watchId": "fda", "agencySlug": "food-and-drug-administration" }
  ],
  "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-document-detected — charged only for a document 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.

• You will never be charged twice for the same document. 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 document 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 documents 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. That same build also had to shorten the durable storage name prefix (the old one, the full actor name, could not fit Apify's 63-character storage-name limit together with a 40-character monitorId), so a monitor that ran on an older build starts from a fresh baseline once. A baseline is never charged.
• 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 a few seconds because Apify's totalRequestCount is eventually consistent). Use it to watch growth, not to make decisions.

Honest limits

• Each check fetches the agency's 100 most recent documents — sufficient for monitoring, since new documents appear at the top. coverage.windowFullCount flags when an agency has published more than fit in that page since the last check (informational, not an error).
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced document number can be re-billed — only matters for extremely high-volume agencies.
• We don't invent data: if the API response shape changes, or a watch's agencySlug is invalid, the run reports it honestly instead of silently returning zero results.

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