Through the OlostepDocumentation Index
Fetch the complete documentation index at: https://docs.olostep.com/llms.txt
Use this file to discover all available pages before exploring further.
/v1/monitors endpoint you can create persistent monitors that run on a fixed schedule, detect page changes, and notify you by email, webhook, or SMS.
- Create a monitor from a natural language
query - Run checks using natural-language schedules
- Deliver alerts via
email,webhook_url, orphone_number(SMS) - List, inspect, update, pause, resume, and delete monitors
- Read monitor snapshot events from private snapshots
query.
Installation
Create a monitor
Create a monitor withPOST /v1/monitors. The endpoint validates your input, provisions the monitor, creates its internal schedule, and returns an active monitor object.
queryis required. If yourqueryincludes a URL, the monitor will focus on that input URL. By default, each run takes a full snapshot of what is being monitored — a picture of the current state of the page. If you want the monitor to track only what’s new or changed between runs (for example, only new blog posts, or only price drops), you must specify that explicitly in thequery; otherwise the full snapshot is captured every run.frequencyaccepts natural-language schedule instructions and defaults to UTC when no timezone is provided.- Exactly one notification target is required:
email,webhook_url, orphone_number(SMS). - Use
output_schemawhen you want structured extraction results. (optional)
Example request
Response
Successful monitor creation returns HTTP202 with a monitor object:
Structured monitor output
Setoutput_schema in the create request when you want monitor extraction results to follow a specific JSON structure. The schema must be valid JSON Schema.
Notification channels
Monitors support one channel per monitor:email: set anemailfieldwebhook: set awebhook_urlfieldsms: set aphone_numberfield (E.164 format, for example+14155552671)
Webhook example
SMS example
Frequencies
Setfrequency in natural language, for example:
every day at 9am America/Los_Angelesevery 5 minutesevery 6 hours
List monitors
Retrieve all monitors for your team withGET /v1/monitors.
By default, deleted monitors are filtered out. Use ?include_deleted=true to include them.
Response shape
Get a monitor
Retrieve a single monitor withGET /v1/monitors/:monitor_id.
Response shape
List monitor events
UseGET /v1/monitors/:monitor_id/events to list snapshot events for a monitor.
This endpoint supports pagination:
limit(default25, max100)cursor(opaque pagination token from a previous response)
snapshot_url so you can fetch private snapshot content securely.
Example
Response shape
cursor is malformed, the endpoint returns:
Update a monitor
Update a monitor withPOST /v1/monitors/:monitor_id.
Supported updates:
metadata(merged with existing metadata; pass empty string values to delete keys)frequency(natural-language schedule text, for exampleevery weekday at 08:30 America/New_York)
frequency, the API recreates the monitor schedule internally. If no timezone is included in the text, UTC is used.
Example request
Pause a monitor
Pause a monitor withPOST /v1/monitors/:monitor_id/pause.
Pausing disables the monitor’s underlying schedule so no further runs are triggered, and sets the monitor’s status to paused. The monitor row, its configuration, and its past snapshots are kept — only future scheduled executions stop. You can resume the monitor later with POST /v1/monitors/:monitor_id/resume.
Only monitors with status of active can be paused. The request body is empty.
Response
On success, returns200 with the monitor and status set to paused:
400—monitor_idmalformed, monitor alreadydeleted, monitor not currentlyactive, or monitor has no underlying schedule.404— Monitor not found.409— The monitor changed state during the pause attempt (no longeractive), or the underlying schedule could not be found.
Resume a monitor
Resume a paused monitor withPOST /v1/monitors/:monitor_id/resume.
Resuming re-enables the monitor’s underlying schedule and sets the monitor’s status back to active. Scheduled runs continue on the existing frequency — no re-creation of the schedule is needed.
Only monitors with status of paused can be resumed. The request body is empty.
Response
On success, returns200 with the monitor and status set back to active:
400—monitor_idmalformed, monitor alreadydeleted, monitor not currentlypaused, or monitor has no underlying schedule.404— Monitor not found.409— The monitor changed state during the resume attempt (no longerpaused), or the underlying schedule could not be found.
Delete a monitor
Delete a monitor withDELETE /v1/monitors/:monitor_id.
Deletion is soft for the monitor row (status becomes deleted) and also removes internal scheduling/shadow-agent resources tied to that monitor.
Example use cases
Below are practical example requests for the/v1/monitors endpoint.
Track uptime issues in the OpenAI API
Run an hourly check that watches the OpenAI API status and emails you when uptime issues are detected.Track product reviews — full snapshot per run
Monitor a product page and deliver every review to a webhook on every run. Because thequery does not ask to dedupe against previous runs, each run captures a full snapshot of the reviews currently on the page (the default behavior). Use this pattern when you want the complete state every time, for example to overwrite a downstream table.
Track only new rental listings — delta from previous run
Monitor a paginated rentals search and run a multi-step pipeline that surfaces only newly appeared listings versus the previous run, then enriches and scores each one before notifying the webhook. The full workflow — paginate, detect new listings against the previous checkpoint, enrich each with crime signals for its location, assign a 1-10 score from price/location/safety, persist state, and notify — is expressed directly as ordered steps in thequery. Because the natural-language steps describe both the extraction and the delta logic, no output_schema is required: the query alone drives what gets fetched, compared, enriched, scored, and delivered.
Common validation errors
The monitor endpoints return clear validation errors for common invalid requests:- Missing
query - Missing
frequency, or invalid schedule instruction - Missing all of
email,webhook_url, andphone_number - Providing more than one of
email,webhook_url, andphone_numberin the same request - Invalid email format
- Invalid webhook URL (must be
httporhttps) - Invalid phone number format (must be E.164, for example
+14155552671) - Invalid
output_schema(must be valid JSON Schema) - Invalid
monitor_idformat