Monitors

Use monitors when a user wants to keep watching a topic instead of running the same search by hand. A monitor has two parts:

• search: the standing query and filters.
• schedule: when the monitor should run.

The saved search is intentionally smaller than a one-off content search. A monitor does not store start_date, end_date, or limit. Omnist computes the date window when the monitor runs, and each dated job uses an internal limit of 1000 results.

Create a Monitor

{
  "name": "Battery supply chain coverage",
  "description": "Coverage of battery materials, export controls, and industrial policy.",
  "search": {
    "query": "battery supply chains export controls",
    "media_types": ["news", "wire", "podcast"],
    "include_domains": ["reuters.com", "ft.com"]
  },
  "schedule": {
    "frequency": "daily",
    "timezone": "America/New_York",
    "run_time": "07:30"
  }
}

Schedules are either hourly or daily. For hourly schedules, set minute. For daily schedules, set run_time in HH:MM format. If you leave the timing out, Omnist uses the monitor creation time in the configured timezone. Timezone defaults to UTC.

Monitors cannot be edited after creation. Delete a monitor when it should stop permanently.

Scheduled Runs

When a monitor runs on schedule, Omnist queues four jobs in parallel:

• the current UTC date
• the previous UTC date
• two days before the current UTC date
• three days before the current UTC date

The timezone in the schedule is for user-facing wall-clock configuration. The content dates are UTC.

Scheduled runs are internal work. They do not count against API rate limits.

Read Results

Use GET /v1/monitors/{monitor_id}/results for the saved result stream. Each result includes the result ID, run ID, observation time, and content item.

Use POST /v1/monitors/{monitor_id}/search when a user wants to search inside a monitor's collected results. It accepts the same request body as POST /v1/content/search.

Backfill Dates

Use POST /v1/monitors/{monitor_id}/backfills to queue specific UTC published dates. The endpoint returns immediately with a parent task_id and per-date queue information.

{
  "dates": ["2026-05-01", "2026-05-02", "2026-05-03"]
}

Check progress with GET /v1/monitors/{monitor_id}/backfills/{task_id}. A backfill date can be queued, running, succeeded, failed, skipped, already complete, or already running.

By default, a backfill skips a date when that date already has a completed backfill whose run date was more than 72 hours after the published date. The response includes already_complete and latest_indexed_content so an integration can decide whether any follow-up is needed.