Skip to main content

2026-07-17 — Machine credentials across the payout surface

OAuth+DPoP credentials carrying the payouts 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). payouts covers the money-movement surface; intelligence covers evaluations and Verifications; both cover webhook subscription management.
  • New error code 403 oauth_client_not_accepted on dashboard-only endpoints reached with an API credential. See Errors.

Changed

  • Beneficiary PII is write-only for machine credentials. PUT /v1/beneficiaries/{id}/pii remains available (your system is the source of the data); GET /v1/beneficiaries/{id}/pii has 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 scope claim 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 the intelligence 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 backing evaluation_id on the attempt’s screening block. See the Verifications guide.
  • verification.* webhook events. verification.link_sent, verification.started, verification.approved, verification.declined, verification.review, and verification.expired are documented in the event catalog. link_sent fires 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 a scope claim (echoed in the token response). Effective access is scopes ∩ capabilities. See Capabilities & Scopes.
  • AI-Compliance-only tier. Accounts can be provisioned with the intelligence capability 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 required Idempotency-Key), GET /v1/intelligence/evaluations (new, cursor-paginated), GET /v1/intelligence/evaluations/{id}, GET /v1/intelligence/evaluations/{id}/evidence, and POST /v1/intelligence/evaluations/validate now run under merchant credentials with the intelligence scope. 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 scoring object: model anton-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 by GET /v1/payouts/{id}/events. See Errors.
  • New error codes. 403 capability_required, 403 insufficient_scope, 409 idempotency_in_flight, 503 idempotency_unavailable are 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 the 429 response.
  • 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/quote now returns quote_id (prefix pq_) and expires_at. Pass quote_id on POST /v1/payouts to lock the quoted fee. Missing or mismatched quotes surface as 422 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-payouts produce deterministic fixtures for SDK testing in the sandbox environment.

Changed

  • Cursor pagination everywhere. Every list endpoint uses limit + opaque cursor with { data, has_more, next_cursor }. Legacy offset pagination 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 the ak_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/rotate returns a fresh raw secret exactly once; GET /v1/webhooks/{id}/secret thereafter returns only the masked suffix (***xxxx). Webhook creates also echo the raw secret once in the create response.
  • Idempotency scoping. Idempotency-Key is scoped per (merchant, path, body) — cross-merchant collisions are impossible. Replays of identical bodies return the original response; replays with a different body return 409 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}/pii endpoint.

Pre-v1.0.0 notes

Early access and beta entries are retained in internal changelogs. Anything on the merchant surface prior to 2026-04-18 should be treated as unsupported.