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, it records the change with its sources and can notify your webhook.
Monitors require access for your organization. Contact support@sixtyfour.ai.
Create and manage monitors through the Monitor Endpoints, the workflow monitor block, or the Monitors page in the Sixtyfour web app. LinkedIn monitors compare selected stored profile fields without research. They share the monitor APIs and notifications. The check flow, tiers, and frequency units below describe research monitors.

​
Concepts

A column cannot be both a key column and a watched field. Two rows with the same subject values are rejected; the workflow monitor block watches such rows once.

​
How a check works

Every tick of the schedule checks each active row.
  • Baseline setup: a watched field whose name matches a column in the input row starts from that cell. A row missing any watched value is enriched at the monitor’s tier: missing fields get their first value, and every supplied value that is already out of date is reported as a change. Rows that supply every watched value skip setup and start with the probe on the schedule.
  • Probe: later checks read the row’s known sources and new search results to decide whether any watched field changed. A check with no likely change ends 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 last reported value is not reported again.
  • 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.

​
Events

Every event from one check shares an event_group_id. LinkedIn monitors write the same event types with different payloads and their own error reasons.

​
Values

Research monitors store every watched value as text. A list answer is stored as its items joined by ; , and an object as key=value pairs joined by ; . A re-check reports a change only when the new value still differs from the baseline after these rules:
  • Case, repeated whitespace, and trailing punctuation are ignored.
  • Numbers compare by value: 1981.0 equals 1981, and 1,200 equals 1200.
  • A list answer compares without regard to order.
  • An empty answer, such as unknown or not found, keeps the previous value and reports nothing.
  • A reworded value judged to state the same fact, such as a school’s full name in place of its short name, is not reported.
Starting values from row cells are stored as text too. Send them as strings, with list items joined by ; . A list or object cell is stored in a different text form, and the first re-check can report it as a change. LinkedIn monitors compare stored profile values exactly. Text values are returned as they are; lists, numbers, and booleans are returned as compact JSON, such as ["Python","SQL"] or true. Any difference is a change, including a list in a new order.

​
How to read changes

​
Frequency

On a research monitor, frequency is a whole number followed by a unit: m (minutes), h (hours), d (days), or w (weeks), for example 90m, 6h, 1d, or 2w. The default is 1d. LinkedIn monitors read m as 30 days, not minutes, and have their own default and range. See Create a LinkedIn monitor.
  • The supported range is 1h to 365d, so 1m (one minute) is rejected on a research monitor.
  • Schedules align to UTC. An hourly monitor fires at the top of each hour, a daily monitor at 00:00 UTC, and a weekly monitor (1w or 7d) on Thursdays at 00:00 UTC. Longer intervals do not follow the calendar: a 30d monitor fires every 30 days, not on the same date each month. next_run_times on every monitor response lists the next three fire times.
  • first_check: "now" (default) runs setup immediately for rows missing watched values. Rows that supply every watched value wait for the schedule. first_check: "next_tick" defers every row 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 Credit Costs. Creating a research monitor, or changing its tier, checks tier access and the team’s spend limit but not your balance. Each check is paid for when it runs. A research check your balance cannot cover is skipped and records an error event. For LinkedIn monitors, see Check behavior.

​
Access and ownership

  • A monitor belongs to the team of the credential that created it. Only that team can see or change it.
  • A monitor runs on behalf of the API key or user that created it. If that key is revoked or expires, the user leaves the organization or team, or the team is archived, its rows pause; see Disabled reasons.
  • 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.