Competitor pricing changes
Use Monitors endpoints to turn competitor pricing changes into repeatable API requests with documented inputs and JSON responses.
Create a monitor with one API call — a page URL for an exact-content diff, or a sitemap URL to track added and removed pages — and get a signed webhook the moment a change is detected. No polling loop to run, no diffing logic to maintain, and management calls (create, list, update, pause, delete) are free.
Use the Monitors API to watch a page or sitemap for changes and get a signed webhook when one is detected, without polling or a diffing pipeline.
Endpoint families
2
Documented params
18
Examples
6
Live catalog snapshot
Active endpoints
6
Methods
DELETE, GET, PATCH, POST
Required params
6
Schema refs
6
{
"platform": "Monitors",
"endpoint": "monitors-create",
"method": "POST",
"path": "/monitors",
"auth": "jwt or apiKey"
}Use cases
Use the Monitors API to watch a page or sitemap for changes and get a signed webhook when one is detected, without polling or a diffing pipeline.
Use Monitors endpoints to turn competitor pricing changes into repeatable API requests with documented inputs and JSON responses.
Use Monitors endpoints to turn product page monitoring into repeatable API requests with documented inputs and JSON responses.
Use Monitors endpoints to turn sitemap/new-page discovery into repeatable API requests with documented inputs and JSON responses.
Managed execution
Crawlora's Monitors API is designed around Monitors's own data surface, not a generic fetch endpoint — combining endpoint-specific request logic, managed infrastructure, parsing, normalization, billing, and Playground-tested examples.
Request behavior for Monitors endpoints is tuned to the platform's own response shapes and edge cases.
Supported Monitors endpoints can use managed proxy routing to improve reliability and reduce infrastructure work.
Dynamic Monitors pages can be routed through managed browser instances where JavaScript rendering is required.
Challenge pages and unusable Monitors responses are detected and surfaced clearly, not silently returned as empty data.
Monitors results are returned as documented JSON instead of raw HTML.
Test the same Monitors route from Docs and Playground before production integration.
Coverage map
These cards are generated from the active endpoint catalog, so the landing page reflects the same API surface used by Docs and Playground.
/monitors/{id}
/monitors
Endpoint catalog
/monitorsCreates a monitor that periodically checks a page or sitemap for changes and can notify a webhook. Free to call -- only completed check runs (services/webmonitor's cron-driven scrape/sitemap fetch) consume credits, at 1 credit per completed run regardless of target type or whether a change was detected. `target_type` defaults to "page" (exact-fingerprint diff of the scraped page). "sitemap" watches the sitemap at `url` for added/removed entries instead, honoring `sitemap.include_patterns`/`exclude_patterns` (shell-style globs matched against each URL's path) and `sitemap.max_urls` (default 5000, hard cap 10000).
/monitorsReturns the caller's own monitors (most recently created first, capped at 100). Free to call.
/monitors/{id}Returns one of the caller's own monitors by id. Free to call.
/monitors/{id}Partially updates one of the caller's own monitors. Free to call. Changing `target_type` or `sitemap` resets the stored diff baseline (fingerprint, snapshot, or URL set), so the next check establishes a fresh baseline instead of comparing against a now-meaningless prior state.
/monitors/{id}Deletes one of the caller's own monitors. Free to call. Does not delete its past check history.
/monitors/{id}/checksReturns the caller's own monitor's most recent check runs (most recent first, capped at 50), including webhook delivery status per run.
Response notes
- `changed`: whether this run detected a difference from the prior baseline. - `diff` (page target) / `added_urls`, `removed_urls` (sitemap target): populated only when `changed` is `true`. - `skipped`: `true` when the run never reached the target (e.g. the account had insufficient credits at the time) — distinct from `error`, which is a target fetch/parse failure. Skipped runs are always free. - `billed`: whether this run actually consumed a credit. - `webhook_deliveries`: one entry per event this run's notification config sent (`change.detected` and/or `run.completed`), each with a `status` of `delivered`, `rejected`, `failed`, or `skipped_unsafe_url`. Example response: ```json { "code": 200, "msg": "OK", "data": [ { "id": "66d2f0c1c2a4e5f6a7b8c9d1", "monitor_id": "66d2f0b1c2a4e5f6a7b8c9d0", "checked_at": "2026-08-22T10:00:00Z", "changed": true, "diff": "- Starting at $29/mo\n+ Starting at $39/mo\n", "billed": true, "webhook_deliveries": [ { "event": "change.detected", "status": "delivered", "status_code": 200, "attempts": 1, "delivered_at": "2026-08-22T10:00:02Z" } ] } ] } ```
Related APIs
Business & Market Intelligence
Turn public GitHub ecosystem signals into structured data for developer-market research, open-source intelligence, recruiting, and AI-agent workflows.
Business & Market Intelligence
Collect public TrustMRR startup marketplace and leaderboard data as normalized JSON for startup research, SaaS discovery, and market intelligence workflows.
Business & Market Intelligence
Add website and competitive intelligence signals from SimilarWeb to research pipelines.
How to scrape Monitors
A monitor is a managed background job: create it once with a target URL and an optional webhook, and Crawlora checks it on your chosen cadence — no cron job, polling loop, or diffing code to maintain on your side.
POST /monitors with a url and cadence_minutes (5 minutes to 7 days). target_type defaults to page (exact SHA-256 fingerprint diff of the scraped content); set it to sitemap to track a sitemap's <loc> entries for additions and removals instead, with optional include_patterns/exclude_patterns glob filters and a max_urls cap.
Set notification.webhook_url (must be https and resolve to a public address) and an optional webhook_secret. Every delivery is signed: X-Crawlora-Signature: t=<unix>,v1=<hmac-hex>, an HMAC-SHA256 digest of "{t}.{rawBody}" — verify it and reject stale timestamps to guard against replay.
notification.events opts into change.detected (fires only when a check finds a difference, the default) and/or run.completed (fires on every completed run, a heartbeat for building "last checked" UI without polling).
GET /monitors/{id}/checks returns the monitor's recent runs — whether each one changed, the diff or added/removed URLs, whether it was billed, and each webhook delivery's status (delivered, rejected, failed, or skipped_unsafe_url).
FAQ
Creating, listing, updating, pausing, and deleting monitors is free. Only a completed check run costs credits — 1 credit per run, whether it's a page or sitemap target, and regardless of whether the run actually found a change. A run that fails, or is skipped because the account has insufficient credits at the time, is always free.
Every delivery carries X-Crawlora-Signature: t=<unix>,v1=<hmac-hex> — an HMAC-SHA256 digest of the string "{t}.{rawBody}" using your webhook_secret. Recompute the digest, compare it in constant time, and reject any timestamp older than a few minutes to reject stale or replayed deliveries.
Yes — set target_type to sitemap and url to the sitemap's URL (a <urlset>, or a one-level <sitemapindex> whose child sitemaps are fetched and merged). Crawlora diffs the set of tracked URLs run to run and reports what was added and removed, honoring optional include_patterns/exclude_patterns glob filters and a max_urls cap (default 5000, hard cap 10000).
Yes — /monitors accepts the same x-api-key used by every other Crawlora endpoint, and every operation (create, list, get, update, delete, check history) is also exposed as an MCP tool, so an agent can manage its own monitors without a human in the dashboard.