# Municipal Agenda Packet Radar (`titan_coder/municipal-agenda-packet-radar`) Actor

Watches US city council/commission meeting portals (CivicClerk, Municode Meetings) you name by URL and reports only agenda documents genuinely new or revised since your last check — agenda, full packet, minutes. A check with nothing new or changed is free.

- **URL**: https://apify.com/titan\_coder/municipal-agenda-packet-radar.md
- **Developed by:** [Radu Furtuna](https://apify.com/titan_coder) (community)
- **Categories:** Business, News, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$20.00 / 1,000 agenda document detecteds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## 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 `fileId`s. 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

```json
{
  "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
`monitorId`s 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)

# Actor input Schema

## `monitorId` (type: `string`):

Name of this monitor's durable history (a-z, 0-9, dash; up to 40 chars).

## `userAgentContact` (type: `string`):

Sent as a descriptive, identifiable User-Agent on every request to the municipal portal (polite-scraping practice, same as SEC EDGAR's fair-use policy) — CivicClerk/Municode do not require an API key, but we still identify ourselves. Give your email or a contact link. Not a secret.

## `watches` (type: `array`):

1-10 objects: {"watchId": "my-city", "portalUrl": "..."}. portalUrl must be a public CivicClerk portal (https://<city>.portal.civicclerk.com/... or https://<city>.api.civicclerk.com) or a Municode Meetings listing (https://meetings.municode.com/PublishPage/index?cid=...\&ppid=...) — the exact council/commission portal you want tracked, not a global search. New watches can be added later under the same monitorId.

## `notifyOn` (type: `string`):

new\_alerts — post the webhook only when new/changed paid documents were delivered; always — post it every run; never — do not call webhookUrl at all.

## `webhookUrl` (type: `string`):

Optional. Receives a digest of delivered (paid) new/changed documents as JSON. HTTPS only.

## Actor input object example

```json
{
  "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"
}
```

# Actor output Schema

## `results` (type: `string`):

Every row this run produced. Key fields: watchId, docType, title, meetingName, meetingDate, url.

## `coverage` (type: `string`):

What this run actually covered and what it charged for: per-target status and reason, documents delivered and billed, and how many Municode file fingerprints could not be determined this run. Enough to reconcile every charge against every row.

## `digest` (type: `string`):

A short human-readable summary of what this run found, written every run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const 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"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("titan_coder/municipal-agenda-packet-radar").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_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",
        },
    ],
}

# Run the Actor and wait for it to finish
run = client.actor("titan_coder/municipal-agenda-packet-radar").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "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"
    }
  ]
}' |
apify call titan_coder/municipal-agenda-packet-radar --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,titan_coder/municipal-agenda-packet-radar"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/yn4ZCo62nCalizk9e/builds/mnIiP3ek8IWrIn2Is/openapi.json