{trusted, confidence}
verdict plus an overall score, risk band, and a machine-readable reason.
The API is bulk and asynchronous: submit an array of inputs, get a request_id
immediately, then read results by polling or receive them on an optional signed
webhook.
Quickstart
Submit your first batch and poll for the result in two calls.
Authentication
Bearer keys, how they’re minted, and what a 401 means.
Reading a verdict
Why
null is first-class and must never be read as false.API reference
The endpoints, schemas, and an interactive playground from the OpenAPI spec.
The shape of an integration
1
Get a key
An admin of an active account mints an API key from the dashboard. The
tf_live_…
secret is shown once. See Authentication.2
Submit a batch
POST /v1/signals with your inputs and the signals you want. You get a request_id
and a 202 straight away.3
Collect results
Poll
GET /v1/signals/{request_id}, or set a webhook_url and receive the completed,
signed payload. Results stay fetchable either way.What you get back
Each person comes back with a per-signal verdict map and an explainable roll-up:signals— each selected signal as{trusted, confidence}. See The verdict model.score(0–100) andband(clear·caution·high_risk) — a transparent, reproducible roll-up over the returned signals. See Scoring and banding.reason— the dominant factor: an override code, or the lowest-scoring signal.
The machine-readable companion to these docs is the OpenAPI 3.1 document at
GET /api/v1/openapi.json, generated from the same signal catalogue and contracts as the
API itself, so the spec and the API cannot drift. The API reference
is rendered directly from it.