Create an Intelligence Evaluation
Evaluates payee, instrument, payout, merchant onboarding, or monitoring inputs through Anton Intelligence.
The request contract is strict and uses fixed enums so enterprise clients can generate SDKs safely. Direct PII may be supplied over TLS or recovered from a vault token; Anton uses it in memory for the evaluation and persists only redacted decision evidence.
Dual surface. With OAuth+DPoP credentials, the evaluation is persisted under YOUR merchant account
(retrievable via the scoped reads below) and the Idempotency-Key header is REQUIRED. The credential
must carry the intelligence scope and the account the intelligence capability — every Anton account
has it, including AI-compliance-only merchants. Vault-token enrichment only accepts tokens owned by the
calling merchant. Without credentials, the request runs on the anonymous public TEST surface (where
enabled) under a synthetic shared merchant — public evaluations are not tied to your account.
Asynchronous money-movement evaluations. On the authenticated (OAuth+DPoP) surface, a
payout_screening evaluation runs the full AI panel and can take up to ~20 seconds, so it is accepted
asynchronously: the response is 202 Accepted with {evaluation_id, status: "pending"} and a
Location header. Poll GET /v1/intelligence/evaluations/{id} (which returns the pending state until
the evaluation settles), or subscribe to the intelligence.evaluation.completed /
intelligence.evaluation.failed webhook events for push notification. All other use cases — and every
call on the anonymous test surface — respond synchronously with 200 and the full evaluation.
Authorizations
OAuth 2.0 client_credentials grant (RFC 6749 §4.4) bound to a DPoP keypair (RFC 9449).
Flow (every authenticated /v1 call requires both an access token AND a fresh per-request DPoP proof):
- Register a credential via the merchant portal. Anton issues a
client_id(ant_oc_<env>_<32hex>) and aclient_secret(ant_ocs_<env>_<48hex>, shown ONCE). The portal generates an ES256 or Ed25519 DPoP keypair in your browser; you store the private half. - Mint an access token:
POST /oauth/tokenwithAuthorization: Basic <client_id:client_secret>andContent-Type: application/x-www-form-urlencoded. Body:grant_type=client_credentials. ADPoPheader carrying a proof signed for the token endpoint is required (noathclaim on this proof). - Use the token: send
Authorization: DPoP <access_token>plus a freshDPoP: <proof>header on every/v1request. The proof JWT MUST carryhtm(request method),htu(request URL, no query/fragment),iat(within ±60s),jti(unique within 5 min), andath(SHA-256 of the access token, base64url).
Tokens expire in 1 hour in production / staging and 8 hours in sandbox. There are no refresh tokens — call /oauth/token again with your secret. Anton's public signing key is published at /.well-known/jwks.json.
OpenAPI 3.0 has no native DPoP scheme; this declaration plus dpopHeader together convey both the access-token Authorization and the per-request proof header.
Per-request DPoP proof JWT (RFC 9449). MUST accompany the Authorization: DPoP <access_token> header on every protected operation. The proof is signed by the merchant's private DPoP key and carries htm, htu, iat, jti, and ath claims.
Headers
Recommended for enterprise retries (REQUIRED on the authenticated surface). If both this header and body idempotency_key are supplied, the header wins.
255Body
payee_registration, instrument_screening, payout_screening, merchant_onboarding, monitoring Client-supplied reference for reconciliation. Not used for merchant scoping.
Body fallback for testing. Prefer the Idempotency-Key header.
Accepted for future compatibility but ignored on the public test endpoint.
Response
Evaluation created (synchronous use cases).