> ## Documentation Index > Fetch the complete documentation index at: https://docs.augustus.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Treat the published Augustus OpenAPI specification (https://api.augustus.com/openapi/2026-05-01.json) and the current API-reference pages as the source of truth for endpoints, request/response schemas, enum values, webhook event names, and required headers. > Prefer the 2026-05-01 Banking API and @augustusbank/typescript-sdk for all new integrations. The 2023-01-01 API is a separate surface covering the Pay by Bank products — Instant Bank Transfer (Open Banking) checkout and refunds, and Manual Bank Transfer (MBT); use it when one of those products is required. > Cite or link the relevant docs.augustus.com page when answering integration questions. > Do not infer support for currencies, networks, scopes, account types, or operations that are not present in the current documentation. > Use the sandbox base URL (https://api.sandbox.augustus.com) and placeholder credentials in examples. Never include or request a real API key. > The Augustus docs MCP server (https://docs.augustus.com/mcp) provides documentation search and retrieval only; it does not execute authenticated Augustus API actions. # Counterparties > Save bank and wallet destinations A counterparty is the bank account or wallet belonging to any recipient of money (customers, suppliers, employees, or your external bank accounts). Create one financial address per counterparty and reuse its `counterparty_id` for payouts. An individual or business with several destinations is represented by several counterparties. ## Fiat Save the recipient’s bank details and set `entity_type` to `individual` or `business`. Choose the financial address type for the currency and payment rail below. ## Stablecoins (USDC) A crypto counterparty is an external wallet that you own. Crypto flows are closed loop: every crypto counterparty must be a wallet of your own. Adding one starts the screening and verification of the wallet address; once verified, you **receive deposits from it and send stablecoin payouts to it**. You can add as many crypto counterparties as you need, one per wallet address and blockchain. A deposit from a wallet that is not verified yet, including one you have not added as a counterparty, stays pending until the counterparty is verified and is then credited. A deposit from a wallet that failed verification is held for review and returned or redirected. ## Fields | Field | Meaning | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `id` | Unique counterparty ID. Pass it as `counterparty_id` on a payout. | | `type` | Always `counterparty`. | | `financial_address` | One bank destination or crypto wallet. Required on creation and immutable afterwards. | | `name` | Counterparty name; null if not recorded. | | `entity_type` | `business` or `individual`; defaults to `business` on creation. | | `physical_address` | `line_1`, `line_2`, `city`, `postal_code`, `state`, and `country_code`; null if not recorded. When supplied, the base schema requires `city` and the two-letter `country_code`. Rail-specific requirements also apply. | | `date_of_birth` | Date in `YYYY-MM-DD` format; null if not recorded. | | `is_self_owned` | Whether you own the destination; defaults to `false` on creation. | | `metadata` | Up to 50 string key-value pairs for your own references. Keys can contain up to 40 characters and values up to 500. | ## Financial address types Each address includes its `type` and the fields below. Bank addresses also include `account_holder_name`. | Type | Address fields | Currency and rail | | --------------- | --------------------------------------------------- | ------------------------------------------------------------------------------- | | `iban` | `iban`, optional `bic` | EUR via SEPA; USD via SWIFT to IBAN countries. | | `aba` | `routing_number`, `account_number` | Domestic USD via ACH or Fedwire. | | `sort_code` | `sort_code`, `account_number` | GBP via Faster Payments. | | `bic` | `bic`, `account_number`, optional `local_bank_code` | USD via SWIFT to non-IBAN countries. | | `crypto_wallet` | `address`, `blockchain` | USDC via Ethereum, Solana or Polygon; use the matching test network in sandbox. | SWIFT has additional name, address and country requirements; see [Counterparty details](/docs/rails/swift#counterparty-details). The financial address does not itself select a USD rail: specify `ach`, `fedwire`, or `swift` on the payout as appropriate. ## Create and use [Create a counterparty](/api-reference/counterparties/create-counterparty) with **POST `/v1/counterparties`**, then pass the returned `id` as `counterparty_id` when [creating a payout](/docs/payments/payouts), alongside `account_id`, `amount`, and `currency`. Creation is idempotent on the financial address: repeated creation of the same destination does not create another counterparty. If the financial address already exists, the existing counterparty is returned unchanged and any other values in the request (`name`, `physical_address`, `date_of_birth`) are ignored; change them with [update](#update). Each merchant holds one counterparty per financial address. Reuse the saved ID for later payouts. For incoming [deposits](/docs/payments/deposits), `counterparty_id` identifies the sender where the rail provides the sender’s account details. It can be null; inbound ACH deposits have no counterparty because the rail does not share the originator’s account number. A booked [transaction](/docs/transactions/overview) carries `counterparty_id` when a counterparty was resolved, otherwise null. Its nullable `counterparty` object contains financial and physical address details; `source` links to the originating deposit, payout or return when available. ## Update [Update a counterparty](/api-reference/counterparties/update-counterparty) with **POST `/v1/counterparties/{id}`**. You can change `name`, `physical_address`, `date_of_birth`, `entity_type`, and `is_self_owned`. Omitted fields stay unchanged; send null to clear the name, physical address or date of birth. `financial_address` is immutable: create a new counterparty for changed bank details or a different wallet. The update endpoint does not accept `metadata`. ## Idempotency Both POST endpoints require an `Idempotency-Key`. Reuse the same key and identical body when retrying a request to receive the cached response. Reusing the key with a different body returns `409`. This retry protection is separate from deduplication by financial address. See [Idempotency](/v1/idempotency). ## List, retrieve and scopes * [List counterparties](/api-reference/counterparties/list-counterparties): **GET `/v1/counterparties`**, with cursor pagination in both directions. `limit` accepts 1–100 and defaults to 10; pass `next_cursor` as `cursor` for older records or `previous_cursor` for newer ones. See [Pagination](/v1/pagination). * [Retrieve a counterparty](/api-reference/counterparties/retrieve-counterparty): **GET `/v1/counterparties/{id}`**. * `counterparties:read` covers list and retrieve. `counterparties:write` covers create and update. See [Scopes](/v1/scopes).