Competitor pricing changes
Monitorsエンドポイントを使えば、「Competitor pricing changes」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
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.
エンドポイントファミリー
2
ドキュメント化されたパラメータ
18
サンプル数
6
ライブカタログスナップショット
稼働エンドポイント
6
メソッド
DELETE, GET, PATCH, POST
必須パラメータ
6
スキーマ参照
6
{
"platform": "Monitors",
"endpoint": "monitors-create",
"method": "POST",
"path": "/monitors",
"auth": "jwt or apiKey"
}ユースケース
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.
Monitorsエンドポイントを使えば、「Competitor pricing changes」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
Monitorsエンドポイントを使えば、「Product page monitoring」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
Monitorsエンドポイントを使えば、「Sitemap/new-page discovery」をドキュメント化された入力とJSONレスポンスによる再現可能なAPIリクエストに変えられます。
マネージド実行
以下の数値はすべて、稼働中のMonitorsエンドポイントカタログから取得しています（エンドポイント6件、ドキュメント化されたリクエストパラメータ18個、公開レスポンススキーマ6件）。DocsとPlaygroundが参照しているカタログと同じものです。
Monitorsのエンドポイントは6件、2つのリクエストファミリーに分類されています（Id、Monitors）。
これらのMonitorsエンドポイントには18個のリクエストパラメータがドキュメント化されており、うち6個が必須です。統合コードを書く前に入力仕様をすべて確認できます。
6件のMonitorsエンドポイントのうち6件が実際のサンプルレスポンスを、6件がドキュメント化されたレスポンススキーマを備えています。最初のリクエストの前に実データの形に合わせて実装できます。
Monitorsのエンドポイントは成功時のスキーマに加えてエラーレスポンス（400、401、404、500）もドキュメント化しています。ブロック、レート制限、レコード欠損は空データではなく型付きのエラーとして返ります。
Monitorsのエンドポイントは3個のホスト型MCPツールとして提供されており、エージェントは同じパラメータと同じJSON契約のまま、追加の実装なしに同じルートを呼び出せます。
カバレッジマップ
/monitors/{id}
/monitors
エンドポイントカタログ
/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).
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.
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.
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.
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.
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.
レスポンスに関する注記
- `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`.
MCPツール monitors_checks
関連API
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.
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.