Retrieve an Instrument
Return a single instrument by ID.
Documentation Index
Fetch the complete documentation index at: https://docs.antonpayments.com/llms.txt
Use this file to discover all available pages before exploring further.
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.
Path Parameters
^ins_[a-zA-Z0-9]+$Response
Instrument.
A payment destination attached to a beneficiary. Credentials (account numbers, wallet addresses, card PANs) are tokenized in Basis Theory and never returned by the API. Only masked display fields and method metadata are exposed.
^ins_[a-zA-Z0-9]+$"ins_01HX8Z9K0M2N3P4Q5R6S7T8UA2"
^ben_[a-zA-Z0-9]+$^mer_[a-zA-Z0-9]+$Credential format of a payment instrument — named by what data is stored, not by the rail that delivers the funds. One credential type can route to multiple rails (e.g. an IBAN can go via SEPA, SEPA Instant, TARGET2, SWIFT, or CHAPS — the rail is selected at payout time).
Query GET /v1/payment-methods for the full country-specific catalog
including per-method credential schemas.
iban, uk_bank, us_bank, ca_bank, au_bank, nz_bank, jp_bank, in_bank, za_bank, ng_bank, ph_bank, cl_bank, co_bank, swift, clabe, cbu, cci, pix, upi, interac, paynow, fps_hk, promptpay, card, crypto, mobile_money active, disabled Whether this is the beneficiary's default instrument for payouts.
RFC 3339 / ISO 8601 timestamp in UTC.
"2026-04-15T14:30:00Z"
RFC 3339 / ISO 8601 timestamp in UTC.
"2026-04-15T14:30:00Z"
ISO 4217 three-letter currency code.
^[A-Z]{3}$"USD"
ISO 3166-1 alpha-2 country code.
^[A-Z]{2}$"US"
Merchant-visible label.
Last 4 characters of the primary credential (account number / PAN / wallet address), for display.
Bank name derived from routing details, for display.
Card network or chain, for display (e.g. visa, ethereum).
Fully masked credential for list views.
"****5432"