Skip to main content
A monitor watches a table of people or companies and re-checks chosen fields on a schedule. When a value changes, the monitor records the change with its sources and can notify your webhook.
Monitors are available to organizations with Monitors enabled. Requests from other organizations return 403. Contact support@sixtyfour.ai for access.

API Reference

See the full request/response schema and parameters in the API Reference.

​
Concepts

A column cannot be both a key column and a watched field. POST /monitors and POST /monitors/upload reject two rows with the same subject values. The workflow monitor block watches such rows once.

​
How a check works

Every tick of the schedule checks each active row in the monitor.
  • Baseline setup: a watched field whose name matches a column in the uploaded row starts from that cell. Setup enriches an incomplete row at the monitor’s tier and reports a change for every uploaded value that is already out of date. Fields with no uploaded value get their first value. Rows whose input supplies every watched field skip full baseline setup and wait for the schedule, where they start with the probe. This applies to API rows, file uploads, upload handles, saved workflow results, and the workflow monitor block.
  • Later checks: the monitor looks at the row’s known sources and fresh search results, then runs a lightweight probe that asks whether any watched field changed since the last check. Most checks end here with a completion event.
  • Re-check: when the probe finds a likely change, the monitor re-derives the watched fields at its tier and records one change event per field whose value moved, with sources, confidence, and a justification. A value equal to the field’s most recently reported value is not reported again, so a field that changes back reports each transition once.
  • Failures: a check that cannot finish records an error event and leaves its time window open. The next check re-examines the same window, so no change is lost to a failed run.

​
Events

Each check has an event_group_id shared by every event it produced.

​
Frequency

frequency is a whole number followed by a unit: m (minutes), h (hours), d (days), or w (weeks). For example 6h, 1d, or 2w. The default is 1d.
  • The supported range is 1h to 30d.
  • 5m is a testing frequency available only to organizations with it enabled. Other organizations receive 403.
  • Schedules align to UTC. An hourly monitor fires at the top of each hour and a daily monitor at 00:00 UTC. next_run_times on every monitor response lists the next three fire times.
  • first_check: "now" (default) runs setup immediately only for rows missing watched values. Rows with every watched value supplied wait for the schedule, even in a mixed table. first_check: "next_tick" defers all rows to the first scheduled fire.
  • Checks never overlap. If a tick is still running when the next one is due, the next one is skipped.

​
Billing

For setup, probe, and re-check charges, see the Credits & Pricing Guide.

​
Access and ownership

  • A monitor belongs to the team of the credential that created it. Only credentials for that team can read or change it. Other teams receive 404.
  • A monitor runs on behalf of the API key or user that created it. If that API key is revoked or expires, or the user leaves the organization or the team, the affected rows pause and disabled_reason is set to key_revoked, owner_removed, or team_removed.
  • When the team’s spend limit is reached, checks are skipped until the limit clears.

​
Errors

For error responses (400, 403, 404, 409, etc.), see Handling Errors.