API
API overview
Five endpoints, three webhooks, one contract file — and the reason this reference cannot drift from it.
The surface
| Method | Path | Purpose | KYB |
|---|---|---|---|
GET | /v1/exposure | Matches against your own address book, with coverage health. Cursor-paged. | required |
GET | /v1/coverage | Coverage health on its own, scoped to your account. | required |
POST | /v1/screen/address | Screen one address. Layer A, optionally layer B. | — |
POST | /v1/decide/deposit | The credit gate. Fail-closed. | required |
GET | /v1/decisions/{decision_id}/evidence | Evidence bundle for one decision, as application/zip. | — |
Three webhooks are delivered to you: exposure.match, exposure.revoked, and coverage.health_changed.
The reference is generated
api/openapi.yaml is the single source of truth for this API. The endpoint reference and the type reference in this section are rendered from that file at build time — they have no source of their own.
That is a structural choice, not a convenience. Hand-written endpoint tables drift from the contract the moment someone ships a field and forgets a doc, and the drift is invisible until an integrator trusts the wrong one. Here there is nothing to forget: if the contract changes, the page changes on the next build, and if the contract is missing the build fails rather than rendering an empty reference.
- Endpoint reference — endpoints, webhooks, the delivery headers, and the error model.
- Types and reason codes — every named schema, every enumeration, and the full reason-code list.
Field descriptions on those pages are reproduced verbatim from the contract. They state what a field is. They do not state how it is derived, and no amount of asking will produce a page that does.
Conventions
Media types. Requests and successful responses are application/json, except the evidence bundle, which is application/zip. Every non-2xx response is application/problem+json and uses the RFC 9457 Problem shape.
Timestamps. RFC 3339, UTC, e.g. 2026-08-24T09:04:11Z.
Amounts. amount_usd is a decimal string, not a number, so nothing is lost to floating point.
Opaque values. Cursors, customer_address_ref, and authority_id are opaque. Do not parse them, construct them, or sort by them.
Unknown fields. Ignore fields you do not recognise. New optional fields and new reason codes are minor changes.
Versioning
Breaking changes go behind a new path prefix. The existing semantics of v1 do not change.
Adding an optional field or a new reason code is a minor change and will happen inside v1. Your client must therefore treat an unrecognised reason code as at least as serious as the accompanying risk_level — never as unknown-therefore-fine.