Exclia
API docs

Get batch job status and results

GET
/batch/{jobId}

Poll a batch job’s lifecycle state. When state is completed, the response includes per-item results: clear or potential_match with evidence and provenance, or an isolated item error. Never an automated excluded boolean.

Authorization

ApiKeyAuth
headerAuthorizationBearer <token>

Your API key, sent as Authorization: Bearer <key>.

Path Parameters

jobId*string

The job id returned by POST /batch.

Response Body

Job status; results present when completed.

application/json
  1. response
jobId*string
Length1 <= length
state*string
Value in"queued""processing""completed"
totalItems*integer
Range0 <= value <= 9007199254740991
completedItems*integer
Range0 <= value <= 9007199254740991
failedItems*integer
Range0 <= value <= 9007199254740991
createdAt*string
Match^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$
Formatdate-time
startedAt*|
Match^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$
Formatdate-time
completedAt*|
Match^(?:(?:\d\d[2468][048]|\d\d[13579][26]|\d\d0[48]|[02468][048]00|[13579][26]00)-02-29|\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\d|30)|(?:02)-(?:0[1-9]|1\d|2[0-8])))T(?:(?:[01]\d|2[0-3]):[0-5]\d(?::[0-5]\d(?:\.\d+)?)?(?:Z))$
Formatdate-time
results?array<|>
curl -X GET "https://example.com/batch/string" \  -H "Authorization: Bearer $EXCLIA_API_KEY"
{  "jobId": "string",  "state": "queued",  "totalItems": 0,  "completedItems": 0,  "failedItems": 0,  "createdAt": "2019-08-24T14:15:22Z",  "startedAt": "2019-08-24T14:15:22Z",  "completedAt": "2019-08-24T14:15:22Z",  "results": [    {      "index": 0,      "outcome": "completed",      "result": {        "status": "clear",        "matches": [          {            "label": "string",            "fields": [              {                "field": "name",                "state": "matched",                "rosterValue": "string",                "listValue": "string",                "strong": true              }            ],            "provenance": {              "sourceList": "string",              "listVersionId": "string",              "retrievedAt": "2019-08-24T14:15:22Z"            },            "score": 0          }        ],        "sources": [          {            "source": "string",            "listVersionId": "string",            "retrievedAt": "2019-08-24T14:15:22Z"          }        ],        "checkedAt": "2019-08-24T14:15:22Z",        "recallCapped": true      }    }  ]}

Enroll an entity in continuous monitoring PUT

Enroll one person or organization in continuous monitoring. The entity is screened immediately and added to your organization’s monitoring (tagged source `api`); the response returns its monitored-record id and current status — `clear` or `potential_match` with per-field evidence and provenance, never an automated "excluded" verdict. From then on it is re-screened whenever a covered source publishes a new immutable list version, and a match-status-change webhook announces any change. Each entity under monitoring accrues one metered record-month per billing month, reported by `GET /usage`.

Live coverage and list versions GET

Every source screened against with its current immutable list_version id, retrieval date, and update cadence, plus honestly-stated gaps. Reads the same coverage metadata as the in-app coverage page, so both agree at the same moment.