Most AI systems read the web once, then operate from a snapshot that starts going stale immediately.
But the web is not static. Prices shift. Competitors ship. Regulations change. Sentiment moves. New listings appear. Product pages update. Service pages go down.
For AI agents to act on real business signals, they need to see the web as it changes, not as it was.
Today, we’re opening access to the Olostep Monitors API.
In short, the Olostep Monitors API lets teams create persistent web monitors using natural-language queries. Each monitor runs on a schedule, captures website changes or snapshots, and sends alerts through email, webhook or SMS. It is designed for AI agents, automation workflows, competitive intelligence, pricing surveillance, listing discovery, and web change detection.
Why we built it
Over the past several months, we’ve worked closely with the AI-native teams already running on Olostep across AI visibility, e-commerce, recruiting and automation.
They use us for scraping, crawling, structured extraction and search. But the same need kept surfacing in every conversation:
“We need a reliable, deterministic way to track changes on the web and turn them into business logic an agent can act on.”
Not a hand-rolled cron job that scrapes a URL and diffs the HTML.
Not a brittle script that breaks the moment the page layout shifts.
A first-class primitive that an AI agent can configure, run and act on - with the same reliability as the rest of their stack.
That’s what Monitors is.
What the Olostep Monitors API does?
A Monitor is a persistent, scheduled observer that watches web pages, captures changes, and triggers alerts or workflows.
You tell it what to track in plain English. The agent generates the workflow, shows you what it will do, runs it on the schedule you set, and alerts you when something changes.
1. Natural-language monitoring queries
Describe what you want to watch, such as:
- Track pricing and stock on this URL.
- Monitor new posts on this competitor blog and summarise them.
- Watch this product page for new reviews.
- Track newly published RFPs on this website.
The agent turns that instruction into a monitorable workflow.
2. Plain-English schedules
Set the monitor frequency in natural language.
For example:
- Every day at 9 am America/Los Angeles
- Every 5 minutes
- Every 6 hours
- Every weekday at 08:30 am America/New York
The API interprets the schedule text and provisions the monitor automatically. If no timezone is provided, the schedule defaults to UTC.
3. Alerts through email, webhook or SMS
Each monitor supports one delivery channel.
You can send alerts through:
- Webhook
- Phone Number for SMS
Only one notification target is required per monitor, keeping the setup simple and predictable.
4. Structured output when you need it
If you want typed results instead of raw text, you can pass an outputschema.
This is useful when monitor results need to flow into a data warehouse, CRM, internal dashboard, enrichment pipeline or agent workflow.
For example, you can ask the monitor to return fields such as:
- Product name
- Price
- Stock status
- Review rating
- Listing URL
- Publication date
- Summary
- Change status
5. Full lifecycle control
Monitors behave like any modern API resource.
You can:
- Create monitors
- List monitors
- Inspect a single monitor
- Update monitor metadata or frequency
- Pause a monitor
- Resume a monitor
- Delete a monitor
- Review monitor events and snapshots
This gives teams the control they need to manage monitoring workflows over time, instead of relying on fragile scripts scattered across infrastructure.
How the Monitors API works
The Monitors API is built around the /v1/monitors endpoint.
A typical workflow looks like this:
- Create a monitor using POST /v1/monitors.
- Describe what to watch in a natural-language query.
- Set the frequency using plain English.
- Choose one delivery channel: email, webhook or SMS.
- Receive alerts when the monitor runs and detects relevant changes.
- Review monitor events and snapshots when you need to inspect historical runs.
- Update, pause, resume or delete the monitor as your workflow changes.
This makes web monitoring programmable, persistent and agent-friendly.
What it looks like in practice
A monitor can be created with one POST request.
The example below creates a monitor that watches a product page for pricing and stock changes.
import requests
requests.post(
"https://api.olostep.com/v1/monitors",
headers={"Authorization": f"Bearer {API_KEY}"},
json={
"query": "Track changes in pricing and stock on https://example.com/products/widget-pro",
"frequency": "every day at 9am America/Los_Angeles",
"email": "alerts@example.com"
}
)That's the whole setup. From there, the monitor runs on its schedule, captures snapshots, and delivers alerts to your chosen destination.
Full snapshots vs change-only monitoring
By default, every monitor run captures a full snapshot of what is being monitored.
That means each run returns a complete picture of the page, workflow or monitored state at that moment.
This is useful when you want to overwrite or refresh a downstream system with the latest full state.
For example, you may want to capture all current product reviews, all current listings on a search page, the full current state of a pricing page, or the latest content from a monitored page.
If you only want the monitor to surface what is new or changed, you should say that directly in the query.
For example:
- Only send newly published blog posts since the previous run.
- Only alert me when the price changes.
- Only return new rental listings that were not present in the previous snapshot.
- Only notify me when stock status changes from unavailable to available.
This lets teams choose between full-state monitoring and delta-based monitoring depending on the workflow.
More advanced monitoring workflows
For more complex use cases, the query can describe an entire multi-step workflow.
A monitor can be instructed to paginate through multiple pages, detect changes against the previous run, extract structured fields, enrich results with external signals, score opportunities, filter low-quality results, and deliver only the final output to a webhook.
For example, one customer monitors paginated rental listings, surfaces only newly appeared listings since the last check, enriches each listing with crime data for its location, scores it from 1–10 based on price, location and safety, then pushes the result to a webhook.
All of that logic lives in the query field as natural language.
Who the Monitors API is built for
The Monitors API is built for teams that need live web signals inside automated systems.
That includes AI agent builders who need fresh web data, e-commerce teams monitoring prices, inventory and reviews, growth teams tracking competitors, launches and market changes, recruiting teams watching job boards and candidate signals, operations teams monitoring service pages and infrastructure updates, data teams feeding structured web changes into internal systems, and automation teams building workflows that respond to external events.
If your system needs to know when something changes on the web, Monitors gives it a reliable way to watch, detect and act.
What customers are using it for
1. Brand and sentiment tracking
Teams can monitor reviews, forums, news, communities and public pages to understand how perception of a company, product or market is shifting over time.
This can help teams identify emerging issues, customer complaints, product feedback or reputational changes before they become larger problems.
2. Competitive intelligence
Monitors can watch competitor blogs, pricing pages, changelogs, documentation, product pages and announcements.
Instead of manually checking for updates, teams can receive alerts when competitors publish something new, change pricing, launch a feature or update positioning.
3. Inventory and pricing surveillance
E-commerce and retail teams can monitor thousands of SKUs across retailers, marketplaces and product pages.
With structured output, pricing and inventory updates can flow directly into a data warehouse, pricing engine, spreadsheet or internal dashboard.
4. Lead and listing discovery
Teams can monitor rental listings, job postings, grants, RFPs, tenders, directories and marketplace pages.
When a new opportunity appears, the monitor can detect it, enrich it, score it and send it to the right workflow.
5. API and service uptime
Monitors can also track critical service pages, status pages and infrastructure updates.
This gives teams another way to detect issues before they affect downstream systems, users or business operations.
The pattern is the same across all of these use cases:
Define the signal. Let the agent watch for it. Act when it changes.
Why not just use a cron job?
Many teams start with a cron job.
That works until it does not.
A hand-rolled monitoring script usually needs custom scraping logic, manual scheduling, change detection, storage, alerting and error handling. It can also become brittle when a page layout changes or when business logic becomes more complex than a simple HTML diff.
Monitors is designed to make scheduled web observation a first-class API primitive.
Instead of stitching together scraping scripts, schedulers, diffing logic and alerting tools, teams can describe the signal they care about and let the monitor run continuously.
That means less infrastructure overhead, fewer brittle scripts and a cleaner path from web change to business action.
The bigger picture
The web is the operating surface of modern work.
It is where business gets done, where decisions get made, and where much of the data your AI systems actually need lives.
But until now, AI has mostly experienced the web as a series of one-time reads — snapshots that go stale the moment they are captured.
Monitors is how we make the web a continuously observable surface for AI agents.
It is the difference between an AI that knows what the web looked like yesterday and an AI that knows what the web is doing right now.
We are starting with the use cases our customers asked for. We will keep going from here.
Get started with the Monitors API
The Monitors API is available today.
Read the Monitors docs to create your first monitor, review the full API reference, or test a workflow in the Olostep Playground.
If you want to talk through a specific use case, reach out to the Olostep team.
Huge credit to Mattia, who drove this end-to-end from the first design doc to launch, and to the rest of the team for shipping it alongside the rest of our roadmap.
