Monitors

A monitor saves a /v1/search or /v1/news request and runs it on a schedule (interval: hourly, daily or weekly, or interval_seconds from 1 hour to 30 days). Each run reports only the results among the top num it hasn't seen before. With endpoint: "webpage" and a url, it checks that page instead and reports it (change: new|changed, with its Markdown) whenever the content changes.

New results are always kept in the monitor's run history (GET /v1/monitors/{id}/runs, results for 24 hours) and, when the monitor has a webhook_url, posted as a signed monitor.results event. The first run is due right away and reports everything it finds (first_run: true).

Each run is billed like the request it makes (1 credit per 10 results, num: 100 is 7; empty and failed runs are free) on the monitor's API key: the key that created it, or last changed or ran it, under that key's limits and the account's spend cap. A monitor pauses itself after 10 failed runs in a row or when its key is revoked; PATCH it with active: true to resume.

A monitor keeps only the fields listed below; any other search field (tbs, start_date, include_content…) is a 400.

Request body

Example request

Authenticate with Authorization: Bearer $SERPKITE_API_KEY (GET requests may pass ?api_key= instead). The official SDKs read SERPKITE_API_KEY for you. See Authentication.

curl https://api.serpkite.com/v1/monitors \
  -H "Authorization: Bearer $SERPKITE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"q":"ai agents funding","endpoint":"news","interval":"daily","webhook_url":"https://example.com/hooks/serpkite"}'

Response fields

Every billed response also carries credit and latency headers (X-Credits-Used, X-Credits-Remaining, X-Request-Id…).

Example response

{
  "id": "01926a3e-9d1f-7a2b-8c3d-4e5f6a7b8c9d",
  "name": "",
  "endpoint": "news",
  "request": {
    "q": "ai agents funding"
  },
  "metadata": null,
  "interval_seconds": 86400,
  "webhook_url": "https://example.com/hooks/serpkite",
  "active": true,
  "next_run_at": "2026-10-04T12:00:00Z",
  "last_run_at": "2026-10-03T12:00:05Z",
  "last_status": "ok",
  "last_error": null,
  "last_new_results": 10,
  "runs": 1,
  "consecutive_failures": 0,
  "credits_used": 1,
  "created_at": "2026-10-03T12:00:00Z"
}

Errors

Errors use one shape: {"error":{"code","message","request_id"}}. Errors are never billed. Full list in Errors.

Notes

• At most 100 monitors per account (403 forbidden beyond that).
• Run now (POST /v1/monitors/{id}/run) requires an active monitor. A paused monitor returns 409 invalid_request; resume it with PATCH {"active": true}, which also schedules an immediate run.
• Changing the saved search with PATCH starts a new baseline: the next run reports every result as new.
• To spot new results a monitor keeps only hashes of the links it has reported; the new results themselves stay in the run history for 24 hours. See Privacy and data retention.

Related

• Scheduled monitoring guide
• Webhooks
• News
• OpenAPI spec