Municipal Agenda Packet Radar

Durable monitor for US city council / commission meeting portals: watches the exact portal URL you give it and reports only agenda documents — agenda, agenda packet, minutes — that are genuinely new or revised since your last check. No API key needed; both supported platforms are public, unauthenticated.

Supported platforms — and only these two

There is no single federal or nationwide API for municipal agendas. Every city runs its own board on one of several vendor platforms, and each vendor exposes a different (or no) public surface. This actor covers exactly two, confirmed live on 12.09.2026 against real municipalities:

1. CivicClerk (<subdomain>.portal.civicclerk.com / <subdomain>.api.civicclerk.com) — a public, unauthenticated OData v4 JSON API. Confirmed working against Seabrook TX, Cook County/Tulsa OK, Portage MI, and Santa Fe NM. Each published file (agenda, agenda packet, minutes) carries a fileId that changes on every revision — confirmed live: the same meeting's "Agenda v. 2" and "Agenda v. 3" had different fileIds. That makes fileId itself a version-stable identifier — no extra hashing needed for this platform.
2. Municode Meetings (meetings.municode.com/PublishPage/index?cid=<CID>&ppid=<PPID>) — a static, server-rendered HTML listing (no JS, no API). Confirmed working against Bremerton WA and Manor TX. Each meeting row links directly to Agenda/Packet/Minutes PDFs on Azure Blob Storage. Unlike CivicClerk, a revised document is not guaranteed to get a new URL, so this actor sends one lightweight HEAD request per tracked file per run and uses Azure's Content-MD5/ETag/Last-Modified+Content-Length as the version fingerprint — a HEAD costs nothing to download, only a status/header round-trip.

Any other platform (Legistar, PrimeGov, iCompass, a custom city CMS, a bare PDF folder…) is out of scope for this version — pointing a watch at one fails cleanly at input validation, before any network call, with a message naming the two supported URL shapes. We do not guess at, or silently degrade to, an unsupported site's structure.

Municode's other, authenticated "PublicApi" product (OAuth2 client-credentials, requires a support-issued client ID/secret) is a different product from the public PublishPage listing this actor uses, and is out of scope — this actor never needs, asks for, or stores any credential.

How it works

1. Each watch is one specific council/commission's public portal URL — never a search or a whole city's worth of boards, only the exact one you name.
2. Every run fetches that portal's most recent window (CivicClerk: last 30 meetings with a published agenda; Municode: last 6 rows of the listing table) and diffs the documents found against a durable checkpoint of document-versions already seen for that watch.
3. Genuinely new or revised documents are pushed to the dataset and billed once each (agenda-document-detected); a check that finds nothing new costs nothing beyond the fixed platform run cost.

Input

{
  "monitorId": "my-city-councils",
  "userAgentContact": "you@example.com",
  "watches": [
    { "watchId": "seabrook-tx", "portalUrl": "https://seabrooktx.api.civicclerk.com" },
    { "watchId": "bremerton-wa", "portalUrl": "https://meetings.municode.com/PublishPage/index?cid=BREM&ppid=d33416d7-25d1-44e6-9d32-55b97fa53824" }
  ],
  "notifyOn": "new_alerts",
  "webhookUrl": "https://example.com/webhook"
}

userAgentContact is sent as a descriptive User-Agent on every request (polite-scraping practice, same spirit as SEC EDGAR's fair-use policy) — neither platform requires a key, but we still identify ourselves.

Add more watches later under the same monitorId — each watch keeps its own independent history. A watchId is permanently bound to the portal it first saw; pointing the same watchId at a different portal later fails the run instead of silently mixing histories.

Billing

Pay-per-event: agenda-document-detected — charged only for a document (agenda/packet/minutes) genuinely new or revised 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 event. 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 event 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 events 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 (29 characters). With a 40-character monitorId that produced a 70-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 (muni-agenda), 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

• Item-level granularity is not available from either platform's public surface as verified in this version. The task this actor was built to serve — flagging a single changed agenda item inside an unchanged packet — needs CivicClerk's Meetings(id)?$expand=items (individual agenda items with their own attachments); every direct attempt at that endpoint returned HTTP 404 during live testing on 12.09.2026 on all four test municipalities, even though the entity set is declared in the service's own $metadata. What is confirmed public and reliable is document-level tracking: the agenda file, the full agenda packet, and minutes, each versioned. In practice this is what most "packet changed" alerts people want — but a purchaser expecting per-item diffing inside an unchanged packet PDF will not get that from this version.
• Each check fetches only a window of recent meetings (30 for CivicClerk, 6 rows for Municode) — sufficient since new/revised documents surface at the top of both platforms' newest-first listings. coverage.windowFullCount flags when a portal has more meetings than fit in that window since the last check (informational, not an error).
• Municode revision detection depends on the file's HTTP HEAD response carrying Content-MD5, ETag, or Last-Modified/Content-Length (Azure Blob Storage provides these; confirmed live). If a HEAD fails or a portal migrates to a host that omits all of them, that one file is honestly skipped for the run (coverage.fingerprintUnknownCount) rather than guessed at.
• seenIds per watch is capped (FIFO by discovery order); an evicted, then re-surfaced item can be re-billed — only matters for extremely high-volume boards.
• We don't invent data: if a portal's response shape changes (CivicClerk drops the expected OData fields, Municode changes its table markup), the run reports it honestly (source_structure_changed: ...) instead of silently returning zero results.

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