Capabilities

GET /v1/banking/capabilities says what the deployment you call can do and what your account can do, in one answer. Every field is read from the state the payout routes act on — the rails registered, the digital-asset assets and the routes the provider opens, the deployment's settings, the send caps, the route policy — so it does not drift from what a request would get. No provider is named: rails are described by kind.

A session, or an API key with accounts:read.

curl -s "$CXC_BASE/v1/banking/capabilities" -H "Authorization: Bearer $CXC_KEY" | jq

Field
`environment`	`sandbox` or `production`
`flows`	The flows, each with a `status`, a short `reason` and its `methods` — below
`digital_assets`	Per asset offered: its `networks`, and `send_onchain`, `send_onchain_to`, `send_internal_to`, `send_iban`, `send_bank` and `swap_to` as in `digital_actions`, for your business's region — with its `limits` per send, day and month in the asset's own units (`null` is not capped)
`digital_rules`	`api_keys_send_only_to_trusted_beneficiaries`, `trusted_beneficiary_cooldown_seconds`, `same_chain_only` (`false` where an asset is sent across chains)
`payout_rails`	Per kind of rail (`bank`, `digital_asset`): what it `holds`, the `currencies` it pays out in, the `schemes` and `networks` it uses, the `countries` it declares, and `simulated` (the sandbox's ledger)
`route_lock`	`ttl_seconds`, `single_use: true`, `locks_rate: false` — see the route lock
`account`	`verified` (may move money), `digital_asset_account` (holds an open USDC account), `digital_assets_held`
`caller`	`kind` (`session`, `api_key`, `master_key`), `key_type`, `scopes`, `delegated`, and a session's seat `permissions` (`null` for a key)
`actions`	Every banking route served here: `method`, `path`, who among API keys may call it (`any_key_with_scope` with its `scope`, `session_or_master_key`, `person_only`, `secret_key`, `authenticated`), and `allowed_by_policy` — whether the route policy admits this caller

allowed_by_policy covers a key's type and scopes, and delegation. It does not cover a session's seat permissions: a member without payouts.create reads true and is refused by the route itself — read caller.permissions.

Flows and methods

`flow`	Its `methods`
`fiat_to_fiat`	`bank_payout`
`fiat_to_stablecoin`	`account_deposit` (EUR to your USDC account's IBAN), `convert`
`stablecoin_to_stablecoin`	`onchain_send`, `cross_chain_send`, `handle_send`
`stablecoin_to_fiat`	`send_back`, `iban_send`, `bank_send`
`swap`	`swap`
`cross_chain`	`cross_chain_send`

Each method has its own status, reason, the request that makes it, and where it names them, its destinations: for bank_send each bank-account kind (type us_bank, gb_bank, clabe, pix) with its currency, country and rails (ach, fedwire, fps, spei, pix) — the kinds offered now, over a rail the provider has enabled for your account. While some kinds are offered, a kind whose rail is not enabled yet is left out of destinations and named in reason. While none is, bank_send is requires_onboarding and its destinations are the kinds waiting on their rails, not payable yet. For cross_chain_send the chains reached across chains; for handle_send the chains another customer's wallet can be on.

`status`	Means
`available`	Offered here, and your account may use it now
`sandbox_only`	Offered here because this is the sandbox; production does not offer it
`requires_onboarding`	Offered here; your account must finish a step first — `reason` says which (verification, a USDC account, an account in each asset of a swap, a bank rail the provider enables)
`not_offered`	Not on this deployment — `reason` says why

Example

From the sandbox, for a business in the EEA, abbreviated (…):

{
  "environment": "sandbox",
  "flows": [
    { "flow": "fiat_to_stablecoin", "status": "available", "reason": "offered",
      "methods": [ { "method": "account_deposit", "status": "available", "…": "…" },
                   { "method": "convert", "status": "not_offered",
                     "reason": "converting into the USDC account is off on this deployment", "…": "…" } ] },
    { "flow": "stablecoin_to_stablecoin", "status": "sandbox_only",
      "reason": "offered in the sandbox; production does not offer it", "methods": [ "…" ] },
    { "flow": "cross_chain", "status": "sandbox_only", "reason": "offered in the sandbox; production does not offer it",
      "methods": [ { "method": "cross_chain_send", "status": "sandbox_only", "…": "…",
                     "destinations": [ { "type": "onchain",
                                         "networks": ["arbitrum", "avalanche_c_chain", "celo", "optimism", "polygon", "stellar"] } ] } ] }
  ],
  "digital_assets": [
    { "asset": "USDC", "networks": ["solana", "base", "ethereum", "tempo"],
      "send_onchain": ["solana", "base", "ethereum", "tempo"],
      "send_onchain_to": ["arbitrum", "avalanche_c_chain", "base", "celo", "ethereum", "optimism", "polygon", "solana", "stellar"],
      "send_internal_to": ["base", "ethereum", "solana"],
      "send_iban": ["EUR"], "send_bank": ["us_bank"], "swap_to": ["EURC"],
      "limits": { "single": "10000", "daily": "50000", "monthly": "250000" } }
  ],
  "digital_rules": { "api_keys_send_only_to_trusted_beneficiaries": true,
                     "trusted_beneficiary_cooldown_seconds": 0, "same_chain_only": false },
  "route_lock": { "ttl_seconds": 900, "single_use": true, "locks_rate": false },
  "account": { "verified": true, "digital_asset_account": true, "digital_assets_held": ["EURC", "USDC"] },
  "caller": { "kind": "api_key", "key_type": "secret", "scopes": ["…"], "delegated": false, "permissions": null },
  "actions": [
    { "method": "POST", "path": "/v1/banking/payouts", "api_keys": "any_key_with_scope",
      "scope": "payments:write", "allowed_by_policy": true },
    { "method": "POST", "path": "/v1/banking/digital-assets/trusted-beneficiaries",
      "api_keys": "person_only", "scope": null, "allowed_by_policy": false }
  ]
}

A business outside the EEA sees gb_bank, clabe and pix beside us_bank once their rails are enabled (rails in GET /v1/banking/kyb/digital-assets). In production, every digital-asset flow other than account_deposit is not_offered until legal sign-off, and no sandbox route is listed.

What it does not promise. Capabilities, like digital_actions, say what is offered — not that a given request will be accepted. The amount, the destination, the caps and the provider are checked when you send.

Flows and methods​

Example​

Flows and methods

Example