The one service that keeps running after the call returns. How a monitor is compiled, what a check is, how size (blocks of 12 queries) × cadence sets the price, what the events feed contains, and how webhooks and pause/resume behave — every number here is the number the sweep bills.
A monitor is a standing watch on a topic. You describe WHAT to watch in natural language (query); STELQ decides HOW: at create time a compile step turns the request into 6–10 diverse search queries (2–4 per named entity for multi-entity watches, up to 120), a list of authoritative domains, a per-topic significance rubric (what counts as minor / notable / major FOR THIS SUBJECT), and candidate direct sources — RSS/Atom feeds, public JSON endpoints, high-signal pages — each confirmed with a live fetch before it enters the plan. The result is the watch_plan on every monitor body: you can read exactly how your topic is being watched.
Preview before you pay. POST /v1/monitors/plan runs the same compile for free and returns watch_plan + pricing. Hand the plan back to create as watch_plan (as-is or edited — trim queries, drop a source) and you skip the second compile and pay exactly the price the plan showed.
| Route | Price | What it does |
|---|---|---|
| POST /v1/monitors/plan | free | compile + price, create nothing |
| POST /v1/monitors/create | $0.05 per block | create; charged on 201 only |
| GET /v1/monitors | free | list with latest event badge |
| GET /v1/monitors/{id} | free | detail: plan, baseline, pricing, recent events |
| GET /v1/monitors/{id}/events | free | the event feed (?limit= ≤100) |
| GET /v1/monitors/{id}/events/{event_id} | free | one check + webhook delivery status |
| PATCH /v1/monitors/{id} | free | edit name / interval / notify_threshold / webhook / queries |
| POST /v1/monitors/{id}/pause · /resume | free | stop / restart checks (and billing) |
| DELETE /v1/monitors/{id} | free | remove the monitor and its record |
Monitors are the only service priced on two axes, and both are visible before you pay. SIZE is the number of compiled queries, metered in blocks of 12 (pricing.size_blocks): a focused topic is one block; a watch over eight vendors might compile to 24 queries = two blocks. Direct sources are free — discovery is the product, not a meter. CADENCE is the check interval you choose: 5m, 15m, 30m, 1h, 2h, 4h, 6h, 8h, 24h or 7d.
| Charge | Amount | When |
|---|---|---|
| create | $0.05 × size_blocks | once, on a 201 from create (a 4xx/5xx is never charged) |
| check | $0.01 × size_blocks | after each COMPLETED check; failed checks are never billed |
Every monitor body carries pricing: { size_blocks, queries, create_usd, per_check_usd, checks_per_day, est_daily_usd }. est_daily_usd is the standing daily cost at the current cadence — a one-block daily watch is $0.01/day (≈ $0.30/month); the same watch every 5 minutes is 288 checks/day ≈ $2.88/day. Use max_queries on plan/create as a price ceiling, or edit queries later with PATCH: the price re-sizes with the plan, never behind your back.
Checks are billed from your prepaid balance by the sweep, not by a request you make. If the balance can't cover a check, the check is skipped and the schedule pushed one interval; the THIRD consecutive skip auto-pauses the monitor with paused_reason: "insufficient_balance". Top up and call /resume — the counter resets. Spend caps on a key apply to the create; standing checks bill the account.
The first check runs within 5 minutes of create and writes the BASELINE — the state of affairs at setup, readable as baseline_md on the detail call. Every later check retrieves the plan's queries and direct sources, diffs the results against everything the monitor has ever seen (each URL is only ever new once), runs a relevance gate that drops landing pages, directories and off-topic SEO, and — when something genuinely new survives — synthesizes ONE event: a significance scored against the baseline using the compiled rubric, a one-line headline, a summary_md with citations, and the new_items[].
| significance | Meaning | Webhook? |
|---|---|---|
| baseline | the first check; establishes the reference state | always |
| none | quiet check — nothing new survived the gate (still recorded, still billed) | never |
| minor | routine / incremental per the rubric | if notify_threshold = all |
| notable | worth attention soon | if notify_threshold ≤ notable |
| major | act-on-it-now | always (any threshold) |
{
"id": "5c1b7e2a-0d4f-4c8e-9a3b-2f6d8e1c4b7a",
"at": "2026-08-28T14:07:12Z",
"status": "completed",
"significance": "notable",
"headline": "CFPB issues proposed rule expanding Reg E error-resolution to P2P fraud",
"summary_md": "**Proposed rule** …",
"new_count": 3,
"filtered_count": 5,
"new_items": [{ "url": "https://www.consumerfinance.gov/…", "title": "…", "snippet": "…" }],
"deep_md": null
}Early checks over-report. Search engines rotate results, so the first few checks after the baseline can surface URLs that are new to the record but not new to the world. The relevance gate and the rubric filter most of it, and monitors quiet down as the seen-record grows. Read significance, not new_count, when deciding what to surface.
Pass webhook (https) on create, or set it later with PATCH. Two event types exist: monitor.baseline fires once, for the first check, regardless of threshold — it is how you verify the integration end-to-end — and monitor.change fires for every later check whose significance clears notify_threshold. Quiet checks (none) never notify. The envelope, headers, signing secret and retry schedule are IDENTICAL to Research webhooks: one receiver, one verify function. See the Webhooks guide for signature verification.
{
"id": "evt_01JX9A4M2KQ7",
"type": "monitor.change",
"api_version": "2026-06-01",
"occurred_at": "2026-08-28T14:07:12Z",
"attempt": 1,
"data": {
"monitor_id": "a01aede0-…",
"monitor_name": "Regulation E watch",
"event_id": "5c1b7e2a-…",
"significance": "notable",
"headline": "CFPB issues proposed rule expanding Reg E error-resolution to P2P fraud",
"new_count": 3,
"result_url": "https://api.stelq.com/v1/monitors/a01aede0-…/events/5c1b7e2a-…"
}
}data.significance / data.headline without a fetch; read data.result_url for the full summary_md and new_items.data.event_id. Delivery is at-least-once with up to 8 attempts over ~24h; GET …/events/{event_id} reports the delivery state, attempts and last status for that check.monitor_create accepts webhook too — the agent's own product can receive the events; the agent reads results back with monitor_get.