Watch a page for changes in what it actually says, with thresholds and keyword triggers so you hear about the changes you care about and not the rotating banner.
Free plan forever · No credit card · Set up in under a minute
A watch takes a copy of the readable text on a page, compares each new reading against the last, and records a version whenever it differs. You decide how big a change has to be before anyone is told, and which words make it matter.
Send the page and how sensitive the watch should be. change_detection is what makes it a watch rather than an uptime check.
curl -X POST https://monitoringdaddy.com/api/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Competitor pricing page",
"url": "https://example.com/pricing",
"interval": 3600,
"request_method": "GET",
"alert_condition": "url_unavailable",
"change_detection": 1,
"change_threshold": 5,
"change_trigger_keywords": "price, plan, per month"
}'Send your key as a bearer token. You will find it under Account → API, and it identifies the account everything is created against.
A successful create returns 201 with the whole resource, including its id — keep that if you intend to update or delete it later.
| Field | Type | What it does |
|---|---|---|
change_detection |
integer | Required, set to 1. This is what makes the resource a watch. |
change_selector |
string | A CSS selector to narrow the watch to one region of the page. |
change_ignore_selectors |
string | Selectors to exclude — carousels, timestamps, cookie bars. |
change_threshold |
numeric | Percentage of the text that must change before it is alertable. |
change_min_words |
integer | A floor in words, so a large percentage of a short page does not fire on its own. |
change_ignore_numbers |
integer | Ignore digits, which suppresses counters and clocks. |
change_trigger_keywords |
string | Only alert when the changed words involve one of these. |
change_trigger_mode |
string | any to require a keyword, excludes to ignore changes containing them. |
GET | /api/v1/monitors?kind=watch | List these |
POST | /api/v1/monitors | Create one |
GET | /api/v1/monitors/{id} | Fetch one |
PUT | /api/v1/monitors/{id} | Update one |
DELETE | /api/v1/monitors/{id} | Delete one |
GET | /api/v1/incidents | Incidents across the account |
GET | /api/v1/monitors/{id}/changes | Every recorded version of this page |
GET | /api/v1/monitors/{id}/changes/{versionId} | The text before, the text after, and the difference |
Narrow the list with kind=watch. Use kind=premium for the subset described below.
Some sites refuse ordinary requests, or build their pages in the browser so there is nothing in the source to compare. Those are read through a paid fetching service that renders the page from a residential address, and a watch on one carries needs_unblocker: true. Because every check on such a page costs us, they are checked no more often than your plan's premium floor — if you create one with a faster interval it is slowed to that on its first check, rather than quietly costing more than your plan covers. Everything else runs at whatever interval you asked for.
Nothing extra. Anything you create through the API counts against the same plan allowance as anything you create in the interface — the same monitors, watches and cron jobs, in the same pool. There is no per-call charge, no separate API tier and no credits to top up. If your plan allows fifty monitors, you may have fifty, however you made them.
The API is the whole product, not a subset of it. Everything the interface can create, the API can create, and both write to the same account — so you can run your own front end, resell monitoring under your own name, or wire checks into a product you already sell, and still log in here to see the same data. Alerts, incidents and status pages all behave identically whichever way the resource was made.
Three levers, and they combine: a selector to watch one region, a threshold so small edits are recorded but not alerted, and keyword triggers so only changes touching your words fire.
Yes, and through the API rather than only in our interface. GET /api/v1/monitors/{id}/changes lists every recorded version with how much moved; GET /api/v1/monitors/{id}/changes/{versionId} returns the text before, the text after and the word-level difference, which is everything you need to render a diff in your own product. Reading history is free and counts against nothing.
Yes, through the premium fetching described above. Those pages are flagged with needs_unblocker so you always know which watches are in that category.
No. A change is read a second time before anything is sent, and if the two readings disagree with each other the difference is treated as noise and recorded without alerting.
Uptime, SSL, domain expiry, page changes and cron jobs, all from one REST API. Free plan, no card, and API access on every paid plan.