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 rejects 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.
  • First check: a watched field whose name matches a column in the uploaded row starts from that cell. The first check enriches the 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. Monitors started by the workflow monitor block skip this full first check for rows whose input already supplies every watched field.
  • 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) checks every row as soon as the monitor is created. first_check: "next_tick" waits for 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

After a row’s first check, every tick bills a probe for that row. The full re-check is billed at the monitor’s tier only for rows where the probe found a likely change. The first check of each row is billed at the monitor’s tier. Switched-off rows and cancelled monitors are not billed. The probe, first check, and re-check are billed separately, and each is charged only if it runs to completion. A probe that completed is still charged when the re-check after it fails. Monitor charges appear in usage logs as monitor_recheck. See Credits & Pricing Guide for more information.

​
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.