List the beneficiaries that this batch created or first referenced.
Covers both the auto-create path (a row with inline beneficiary
details for which no matching beneficiary existed — Anton creates one
and tags it with source_batch_id) and the match path (a row that
resolved by external_id or display-name heuristic against an
existing beneficiary, but where this batch was the first to touch it).
Returned beneficiaries have created_via: "batch" and a
source_batch_id equal to the batch ID in the URL. The response is
merchant-scoped — cross-merchant ID probing returns 404.
This endpoint may return 501 not_configured on API instances where
the beneficiary service is not wired into the batch handler (not the
case for production or sandbox).
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.
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):
client_id (ant_oc_<env>_<32hex>) and a client_secret (ant_ocs_<env>_<48hex>, shown ONCE). The portal generates an ES256 or Ed25519 DPoP keypair in your browser; you store the private half.POST /oauth/token with Authorization: Basic <client_id:client_secret> and Content-Type: application/x-www-form-urlencoded. Body: grant_type=client_credentials. A DPoP header carrying a proof signed for the token endpoint is required (no ath claim on this proof).Authorization: DPoP <access_token> plus a fresh DPoP: <proof> header on every /v1 request. The proof JWT MUST carry htm (request method), htu (request URL, no query/fragment), iat (within ±60s), jti (unique within 5 min), and ath (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 /v1/.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.
^bat_[a-zA-Z0-9]+$Items per page. Maximum 100.
1 <= x <= 100Opaque cursor returned by a previous list response. Omit for the first page.
Paginated list of beneficiaries created or first referenced by this batch.