Validate an Intelligence Evaluation
Validates the strict request contract without creating or persisting an evaluation. Works on both the authenticated and (where enabled) anonymous public surface.
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
Optional. If both this header and body idempotency_key are supplied, the header wins during validation mapping.
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
Request is valid and can be mapped to an internal event.