Competitor pricing changes
Usa los endpoints de Monitors para convertir competitor pricing changes en solicitudes API repetibles con inputs documentados y respuestas JSON.
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.
Familias de endpoints
2
Parámetros documentados
18
Ejemplos
6
Snapshot en vivo del catálogo
Endpoints activos
6
Métodos
DELETE, GET, PATCH, POST
Parámetros obligatorios
6
Referencias de esquema
6
{
"platform": "Monitors",
"endpoint": "monitors-create",
"method": "POST",
"path": "/monitors",
"auth": "jwt or apiKey"
}Casos de uso
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.
Usa los endpoints de Monitors para convertir competitor pricing changes en solicitudes API repetibles con inputs documentados y respuestas JSON.
Usa los endpoints de Monitors para convertir product page monitoring en solicitudes API repetibles con inputs documentados y respuestas JSON.
Usa los endpoints de Monitors para convertir sitemap/new-page discovery en solicitudes API repetibles con inputs documentados y respuestas JSON.
Ejecución gestionada
Cada cifra de abajo se lee directamente del catálogo de endpoints en vivo de Monitors — 6 endpoints, 18 parámetros de solicitud documentados y 6 esquemas de respuesta publicados — el mismo catálogo contra el que corren Docs y Playground.
6 documented Monitors endpoints, grouped into 2 request families — Id and Monitors.
18 request parameters are documented across those Monitors endpoints, 6 of them required — the full input contract is public before you write any integration code.
6 of the 6 Monitors endpoints ship a recorded example response, and 6 carry a documented response schema — you can code against the real JSON before the first request.
Monitors endpoints document their error responses (400, 401, 404 and 500) alongside the success schema, so a block, a rate limit, or a missing record comes back as a typed error rather than silently empty data.
3 hosted MCP tools back the Monitors endpoints, so an agent can call the same routes with the same parameters and the same JSON contract, with no custom glue.
Mapa de cobertura
/monitors/{id}
/monitors
Catálogo de endpoints
/monitorsCreates a monitor that periodically checks a page or sitemap for changes and can notify a webhook. Free to call -- only completed check runs 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 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).
Herramienta MCP monitors_list
/monitorsLists the website-change monitors on your account, most recently created first, up to 100. Each monitor has its `target_type` (`page` or `sitemap`), URL, name, cadence in minutes, enabled flag, last checked and last changed times, next check time, failure count, last error, and notification and sitemap settings.
Herramienta MCP monitors_list
/monitors/{id}Returns one of your website-change monitors by `id`. The monitor includes its `target_type` (`page` or `sitemap`), URL, name, check cadence in minutes, enabled flag, last and next check times, failure count and last error, plus notification and sitemap settings.
Herramienta MCP monitors_update
/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.
Herramienta MCP monitors_update
/monitors/{id}Deletes one website-change monitor by its `id`, which must belong to the calling account. Returns `deleted: true` on success. The monitor's past check history is not removed.
Herramienta MCP monitors_update
/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.
Notas de la respuesta
- `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`.
Herramienta MCP monitors_checks
APIs relacionadas
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.
Cómo hacer scraping de 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).
Preguntas frecuentes
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.