Skip to main content
POST
Create a monitor

​
Overview

A monitor re-checks pages on a schedule and compares each one with the previous check. Instead of polling a pricing page, a changelog or a policy page yourself, you get a webhook with just the diff when something changes.
1

Create

POST /monitor with what to watch, how often, and — optionally — a goal describing which changes matter.
2

Baseline

The first check records every page. Nothing is announced: every page is new by definition.
3

Check

Each scheduled check fetches every page again and marks it same, new, changed, removed or error, with a diff.
4

Get told

Changes that match your goal are POSTed to your webhook. You can also read any check with GET /monitor/{id}/checks/{checkId}.

​
Example request

​
Example response

The status is 201 Created. Keep the webhook.secret — you need it to verify each webhook. You can read it again with GET /monitor/{id}.

​
What to watch

A monitor has up to 50 targets, of two kinds. You can mix them. One check fetches at most 500 pages across all targets — every scrape URL plus every crawl’s limit.
A crawl can only report a page as removed when it runs out of pages to visit. A crawl that stops at its limit cannot tell a page that was taken down from one it never reached, so it reports no removals. Give a crawl target a limit comfortably above the section’s size if removals matter to you.

​
Schedules

Write the schedule as a phrase or as five-field cron, in any IANA timezone:
Phrases you can use include every 30 minutes, every 15 minutes starting at :07, hourly, every 2 hours, daily, daily at 9am, daily at 5:30 PM, every weekday at 9am, weekly, every monday at 8:00 and monthly.
  • Runs must be at least 5 minutes apart — every gap, not just the first.
  • Phrases that leave the minute open (hourly, daily) get a fixed minute of their own, so monitors created at the same time do not all fire at once.
  • The response always shows the cron the monitor actually runs on.
  • Times follow the timezone across daylight-saving changes.

​
Detecting changes

Each page of each check gets one status: By default the page’s markdown is compared, and diff.text holds a unified diff with the same hunks structured in diff.hunks. Whitespace and line-ending churn never counts as a change. To watch specific facts instead of the whole text, use the json mode. Describe the fields, and each check extracts them and compares them field by field:
A page is then changed only when a tracked field changes, and diff.fields says exactly which one: plans[0].price: "$19/mo" → "$24/mo". Pass json_schema instead of, or as well as, json_prompt to fix the shape. Use "modes": ["json", "markdown"] to get both diffs.
Most false alarms come from page furniture: a “last updated” date, a rotating testimonial, a visitor counter. Leave them out with scrape_options.exclude_selectors, or switch to the json mode and track only what you care about. Images are left out of the comparison by default, because their URLs change with every deploy.

​
Goals and judging

Add a goal — one plain sentence about what you want to be told — and every changed, new or removed page is judged against it:
Each judged page gets is_meaningful and a judgment with a reason. Pages ruled not meaningful are still recorded on the check, but don’t send a webhook. Good goals restate their scope (“the Pro plan”, “the top 10”, “API changes”) and name exclusions only when they matter. Judging is on whenever a goal is set; pass judge_enabled: false to keep a goal without judging. The first check’s baseline is never judged.

​
Webhooks

With a webhook, two events are POSTed to you: Every request is signed with the monitor’s webhook.secret. Answer 2xx within 10 seconds; failures are retried after 1, 5 and 15 minutes. The webhook URL must use https://.

​
Credits

Creating, reading and changing a monitor is free. Each check is billed to the API key that created the monitor:
  • 1 credit per page fetched — the /scrape rate, or 4 on targets tracking json.
  • 1 credit per page judged against your goal — changed, new or removed pages only.
Pages that fail to load are never charged, and neither are skipped checks. estimated_credits_per_month is an upper bound: it assumes every page is fetched and judged on every check. A check never spends more than the key has left. When credits run out partway, it stops and reports partial; when the key has none at all, the check is recorded as skipped_no_credits and the monitor keeps its schedule, resuming as soon as credits refill.
A monitor bills on every check for as long as it is active. A crawl target with limit: 100 on a 5-minute schedule fetches 28,800 pages a day. Start small, and pause monitors you are not using.

​
Limits

Monitors need a direct Prefetch API key. They are not available through RapidAPI, which meters usage from a response header — and a scheduled check runs when there is no response to carry one.

​
Next

GET /monitor/{id}/checks/{checkId}

Read what a check found, page by page.

monitor.page webhook

The event you receive, and how to verify it.

POST /monitor/{id}/run

Run a check now instead of waiting for the schedule.

PATCH /monitor/{id}

Pause, resume, or change what a monitor watches.

Authorizations

​
X-API-Key
string
header
required

Your Prefetch API key. Obtain one from the dashboard.

Body

application/json
​
name
string
required
Maximum string length: 256
Example:

"Competitor pricing"

​
schedule
object
required

Exactly one of cron or text. A bare string is accepted too, and read as cron when it has five cron fields.

​
targets
(Scrape target · object | Crawl target · object)[]
required

What to watch. At most 500 pages per check across all targets.

Required array length: 1 - 50 elements

Watches a fixed list of pages, each fetched the way GET /scrape would fetch it.

​
goal
string | null

What you want to be told about, in one plain sentence. With a goal, every changed page is judged against it, and only meaningful changes send a monitor.page webhook. 1 credit per page judged.

Maximum string length: 2000
Example:

"Alert me when a plan price or its included features change"

​
judge_enabled
boolean

Judge changes against the goal. Default: true when a goal is set.

​
webhook
object
​
retention_days
integer
default:30

How long check history is kept.

Required range: 1 <= x <= 365

Response

Monitor created.

​
success
enum<boolean>
required
Available options:
true
​
data
object
required
​
meta
object
required