Updates. Fixes.
Improvements.

Record detail is free after a paid query

GET /api/v1/screening/entities/{id} is not charged again for a record id one of your paid queries returned in the last 24 hours, for an API key and a portal session alike. Any other id is charged as before (ON8-6857).

New 401 code: API_KEY_WRONG_SCHEME

An on8 key sent with the Bearer scheme or in the X-API-Key header now answers 401 API_KEY_WRONG_SCHEME, with a message that names the format to use, instead of 401 UNAUTHORIZED (ON8-6862). A client that branches on UNAUTHORIZED for a bad header should handle both.

Validation messages name the failing fields

A 422 VALIDATION_ERROR message now repeats the details and names each failing field; "One or more validation errors occurred." remains only when there are no details (ON8-5521).

Public API base URL: https://api.on8.ai

API-key integrations call https://api.on8.ai, with every route under /api/v1 as before (ON8-5326).

Identity scoring model ims-2

A birth date that agrees with the record no longer scores below the engine's own name score (ON8-5349). identity_match.model_version and identity_model read ims-2; store the version with a screening result.

• Full date that agrees: at least the engine's score plus 5, at most 99
• Year that agrees: at least the engine's score plus 2, at most 97
• Applies to the structured match endpoints, fuzzy-mode general search and the identity score on batch job rows; not to exact-mode general search, which has no name score

batch.completed webhook

A batch job that reaches Completed, PartialFailure or Failed sends batch.completed to the endpoints subscribed to it (emitted since ON8-4481, subscribable since ON8-4686). The payload carries jobId, status, fileName, subjectCount, processedCount, flaggedCount, errorMessage and completedAt.

Batch jobs and monitoring readable with an API key

The screening:write key that creates batch jobs and enrols monitoring subjects can now read them back (ON8-4481, ON8-4493).

• GET /api/v1/portal/batch/jobs, /jobs/{id}, /jobs/{id}/results and /jobs/{id}/results.csv; POST /jobs/{id}/requeue
• GET /api/v1/portal/monitoring/subjects and /stats
• Paged lists answer { success, data, meta }

Topic and adverse-media category taxonomies

GET /api/v1/screening/topics and GET /api/v1/screening/adverse-media/categories are readable with an API key and not billed (ON8-4317). The general search now refuses a topic it does not know with 400 VALIDATION_ERROR instead of letting it be ignored (ON8-4040).

options.ip no longer filled in on API-key orchestration calls

POST /api/v1/orchestrate/screen used to put the connection's IP into options.ip, which on an API-key call is your server's address, not your applicant's (ON8-4501). Send the end user's IP in options.ip yourself; portal sessions still get it added.

PEP search returns matched hits only

POST /api/v1/screening/pep no longer returns the candidates a fuzzy screen scored below the threshold (match: false), and totalHits no longer counts them, as the sanctions search already did (ON8-3989).

Screening API rate limit (120 requests/minute)

The /api/v1/screening endpoints now enforce 120 requests per minute per tenant: one window shared by all of the tenant's API keys and portal users. Requests over the limit return 429 RATE_LIMIT_EXCEEDED with a Retry-After header telling a well-behaved client when to retry.

• 120 requests/minute per tenant on /api/v1/screening, shared by every key of the tenant
• Over-limit requests return 429 RATE_LIMIT_EXCEEDED
• 429 responses carry a Retry-After header - back off and retry after that interval

Public API v1

Sanctions and PEP screening, KYB lookups, pre-KYC checks and batch screening are live under /api/v1. Entries are published as they ship; there is no v2.