2026-07-17 — Machine credentials across the payout surface
OAuth+DPoP credentials carrying thepayouts scope now exercise the full money-movement mutation surface. Previously, machine callers could read but not mutate on several payout-surface endpoints; credential scopes now map directly to the permissions each endpoint requires, so a payouts-scoped credential creates and cancels payouts, manages beneficiaries and instruments, uploads and confirms batches, executes FX, and manages webhook subscriptions — end to end.
Added
- Scope-mapped permissions for machine credentials. Each credential scope carries a fixed permission set enforced per endpoint (least privilege — SOC 2 CC6.1/CC6.3).
payoutscovers the money-movement surface;intelligencecovers evaluations and Verifications; both cover webhook subscription management. - New error code
403 oauth_client_not_acceptedon dashboard-only endpoints reached with an API credential. See Errors.
Changed
- Beneficiary PII is write-only for machine credentials.
PUT /v1/beneficiaries/{id}/piiremains available (your system is the source of the data);GET /v1/beneficiaries/{id}/piihas been removed from the public API surface. Detokenized PII readback — beneficiary PII, verification name reveal, captured documents — exists only in the merchant dashboard, admin-gated and audit-logged per access. A leaked API credential cannot harvest identities. - Approval decisions stay human. Payout approve/reject (maker-checker) rejects machine credentials — an approver must be a signed-in portal user distinct from the creator.
- Access tokens without a
scopeclaim now grant nothing. The transitional full-scope default for pre-scope-era tokens has been removed; every legitimately minted token has carried the claim since it shipped, and a claim-less token now fails closed.
2026-07-16 — Verifications API
Additive, non-breaking. The verification module — previously reachable only through the merchant dashboard — is now part of the public API for OAuth+DPoP credentials carrying theintelligence scope.
Added
- Verifications API. KYC/KYB-as-a-service over hosted flows: create verification subjects (
POST /v1/verification-subjects), list and read them, re-verify, resend / regenerate / revoke links, resend per-owner (UBO) links, and read funnel stats (GET /v1/verification-stats). Every completed verification is sanctions-screened through Anton Intelligence, with the backingevaluation_idon the attempt’sscreeningblock. See the Verifications guide. verification.*webhook events.verification.link_sent,verification.started,verification.approved,verification.declined,verification.review, andverification.expiredare documented in the event catalog.link_sentfires as the delivery receipt for Anton-delivered hosted links.
Security
- PII-free machine surface. Subject and owner names are masked on every API read; the audited name-reveal and captured-document viewing remain dashboard-only (admin, per-access audit trail). Hosted links are secret-once: returned only by the response that minted them.
2026-06-10 — Capabilities, AI-Compliance tier, authenticated Intelligence
Additive, non-breaking changes to the v1 contract. Existing integrations are unaffected: every existing account keeps both capabilities, and every existing credential behaves as full-scope.Added
- Account capabilities and credential scopes. Every merchant account carries a capability set (
payouts,intelligence); every OAuth client carries a scope set fixed at creation and embedded in access tokens as ascopeclaim (echoed in the token response). Effective access isscopes ∩ capabilities. See Capabilities & Scopes. - AI-Compliance-only tier. Accounts can be provisioned with the
intelligencecapability only — full access to Anton Intelligence, dashboards, webhooks, and credential management, with the entire payout surface structurally unreachable (403 capability_required). - Authenticated Intelligence API.
POST /v1/intelligence/evaluations(with requiredIdempotency-Key),GET /v1/intelligence/evaluations(new, cursor-paginated),GET /v1/intelligence/evaluations/{id},GET /v1/intelligence/evaluations/{id}/evidence, andPOST /v1/intelligence/evaluations/validatenow run under merchant credentials with theintelligencescope. Evaluations persist under your account and reads are strictly merchant-scoped. A dedicated 120 req/min per-merchant limit applies on top of the global quota. The anonymous public test surface keeps its existing contract where enabled. - Intelligence scoring block. Evaluation responses now include a
scoringobject: modelanton-scoring-v1, a 0–1000 scale, an overall score and risk level, and five dimensions (Transaction Risk, Onboarding Risk, Transaction Monitoring, Anomaly Detection, Graph Intelligence). - Stable payout failure codes. Terminal asynchronous payout failures now record a machine-readable
failure_code+failure_category(and, for provider failures,rail_error_code/rail_provider/rail_provider_code) in the payout event metadata served byGET /v1/payouts/{id}/events. See Errors. - New error codes.
403 capability_required,403 insufficient_scope,409 idempotency_in_flight,503 idempotency_unavailableare now documented across the error catalog.
Changed
X-RateLimit-*headers documented in the OpenAPI spec.X-RateLimit-Limit/-Remaining/-Reset(present on every response since v1.0.0) are now part of the published spec on the429response.- OpenAPI 3.1 hygiene. Nullable fields now use
type: [string, "null"]per OpenAPI 3.1; the spec lints clean.
v1.0.0 — 2026-04-18
The v1.0.0 merchant contract is now frozen. Merchant integrations built against this surface will not break in minor or patch releases. Breaking changes will only arrive in a future v2.Added
- Bindable pricing quotes.
POST /v1/pricing/quotenow returnsquote_id(prefixpq_) andexpires_at. Passquote_idonPOST /v1/payoutsto lock the quoted fee. Missing or mismatched quotes surface as422 quote_expired/422 quote_already_used/422 quote_mismatch. - Per-merchant rate limits. The 1,000 requests-per-minute base quota is per merchant (not per IP). Multi-seat merchants behind shared egress NATs now get coherent quota accounting. Specific merchants can be provisioned at 2×/5×/10×/20× the base by contacting support.
- Sandbox seeding.
POST /v1/merchant/sandbox/reset,/seed-beneficiaries, and/seed-payoutsproduce deterministic fixtures for SDK testing in the sandbox environment.
Changed
- Cursor pagination everywhere. Every list endpoint uses
limit+ opaquecursorwith{ data, has_more, next_cursor }. Legacyoffsetpagination has been removed. - Monetary amounts are decimal strings, scaled per currency. Amount fields are always emitted at the currency’s canonical scale (USD/EUR at 2 decimals, JPY at 0, BHD at 3, BTC at 8, USDC at 6). Never parse as a float.
- ID prefix scheme normalised.
pay_*(payouts),ben_*(beneficiaries),ins_*(instruments),bat_*(batches),whk_*(webhook subscriptions),evt_*(events),dlv_*(deliveries),pq_*(pricing quotes),fxq_*(FX quotes),fxx_*(FX exchanges),mer_*(merchant). Your API-key secrets are issued by the dashboard with theak_live_*/ak_test_*prefix. - Corridor responses no longer expose
provider. Anton’s rail graph is a commercial secret; the merchant view emits only the merchant-observable fields. - Timestamps are RFC 3339 with nanosecond precision, in UTC.
- Webhook secret rotation.
POST /v1/webhooks/{id}/secret/rotatereturns a fresh raw secret exactly once;GET /v1/webhooks/{id}/secretthereafter returns only the masked suffix (***xxxx). Webhook creates also echo the raw secret once in the create response. - Idempotency scoping.
Idempotency-Keyis scoped per(merchant, path, body)— cross-merchant collisions are impossible. Replays of identical bodies return the original response; replays with a different body return409 idempotency_conflict.
Security
- Cross-merchant policy. The merchant API never exposes counts, identities, or adverse-event signals derived from other merchants’ activity — not even as booleans. Anton-network intelligence is aggregated only into opaque verification signals that are indistinguishable from external-provider outcomes.
- PII isolation. All beneficiary PII and payment instrument details are tokenized in Basis Theory. Raw values are only ever returned from the dedicated
GET /v1/beneficiaries/{id}/piiendpoint.