USAspending Contract Award Monitor

Durable monitor for new federal contract awards from a US government agency, via the official, free USAspending.gov API. No API key needed.

Why

Government contractors, competitive-intelligence teams, and journalists want to know the moment an agency awards a new contract — who won it, for how much, when. Existing scrapers on Apify only do a one-off pull or focus on open opportunities (not awards already made); none durably track what's already been seen and pay only for genuinely new awards.

How it works

1. Each watch is one federal agency you track by its exact official name (e.g. "Environmental Protection Agency" — full list at usaspending.gov/agency).
2. Every run searches that agency's contract awards from the last 30 days (a rolling window, since awards can be registered in the system a few days after signing) and diffs them against a durable checkpoint of award IDs already seen for that watch.
3. Genuinely new awards are pushed to the dataset and billed once each (new-award-detected); checking an agency with nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "my-agencies",
  "watches": [
    { "watchId": "epa", "agencyName": "Environmental Protection Agency" }
  ],
  "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-award-detected — charged only for an award 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 award, 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 searches a rolling 30-day window (not "since last run") to absorb the system's own registration lag — an award that appears late is still caught by the rolling window.
• Only contract awards (types A/B/C/D) are covered in this version — grants, loans, and other assistance award types are out of scope.
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced award ID can be re-billed — only matters for extremely high-award-volume agencies.
• We don't invent data: if the API response shape changes, or a watch's agencyName doesn't match an exact official agency name, the run reports it honestly instead of silently returning zero results.

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