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 last_check_id to inspect the latest attempt and last_successful_check_id to retrieve the comparison baseline.

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.

Change detection and failures

Each successful Monitor Check points to its previous_check_id. Fidera compares stable Match keys and material hashes to produce new, changed, unchanged, and removed entries in the new Check's nested matches evidence. Removed entries use present=false; prior Check evidence is never deleted.

Subscribe to:

• monitor.check_completed for every successful run;
• monitor.matches_changed when at least one Match is new, changed, or removed;
• monitor.failed for failed execution.

A failed run updates the latest-attempt pointer and failure evidence but never rewrites last_successful_check_id.