Monitors

A Monitor periodically creates a new immutable Check for an Applicant and a stable subject set. The Monitor holds schedule and lifecycle state; the latest Check holds the actual evaluation evidence.

Create a Monitor

{
  "applicant_id": "7f9ee48f-4b03-4b51-93c8-629872f067cc",
  "external_id": "customer-481-monitor",
  "datasets": ["sanctions", "pep"],
  "run_immediately": true,
  "subjects": [
    {
      "reference_id": "customer-481",
      "type": "person",
      "role": "customer",
      "name": "Jane Example",
      "date_of_birth": "1990-01-01"
    }
  ]
}

run_immediately defaults to true. Retain the returned Monitor ID and inspect its latest_check_id to retrieve evidence from the most recent run.

Lifecycle operations

• Pause or resume with PATCH /v1/monitors/{monitor_id}.
• Request a run with POST /v1/monitors/{monitor_id}/run.
• Replace the complete subject set with PUT /v1/monitors/{monitor_id}/subjects.
• Filter and paginate all Monitors with GET /v1/monitors.

Subject replacement is whole-resource replacement, not an append. Send every subject that should remain monitored.

Deduplication and failures

An unchanged actionable hit remains risk-active without creating duplicate operator work on every run. A material subject, source, policy, or match change can reopen the workflow.

Subscribe to monitor.failed and surface the Monitor's failure evidence. A failed run never rewrites the last successful Check.