> ## Documentation Index > Fetch the complete documentation index at: https://docs.cdp.coinbase.com/llms.txt > Use this file to discover all available pages before exploring further. # Create Solana account > Creates a new Solana account. ## OpenAPI ````yaml post /v2/solana/accounts openapi: 3.1.0 info: title: Coinbase Developer Platform APIs description: >- The Coinbase Developer Platform APIs - leading the world's transition onchain. license: name: MIT url: https://opensource.org/licenses/MIT version: 2.0.0 contact: name: Coinbase Developer Platform email: cdp@coinbase.com url: https://cdp.coinbase.com servers: - url: https://api.cdp.coinbase.com/platform description: The production server of the CDP APIs. security: - apiKeyAuth: [] tags: - name: Accounts x-audience: public x-slo-tier: tier: beta description: >- The Accounts APIs enable developers to create and manage accounts for their Entity. An Account is a container that holds assets and can be used for transacting. Accounts can be of different types including entity accounts, prime accounts, and business accounts. Support for Customer-owned accounts is in development. - name: Deposit Destinations x-audience: public x-slo-tier: tier: beta description: >- Deposit Destinations allow you to manage where funds can be deposited into your accounts. ## Crypto Deposit Destinations Crypto deposit destinations are cryptocurrency addresses that you can generate and fetch via the API. Once created, these addresses can receive cryptocurrency payments on their specified network and will settle in your account balance. **Metadata:** You can attach metadata to any deposit destination you create to track the purpose or source of deposits. **Example:** ```json { "depositDestinationId": "depositDestination_123", "accountId": "account_456", "type": "crypto", "crypto": { "network": "base", "address": "0x742d35Cc6634C0532925a3b844Bc454e4438f44e" }, "target": { "accountId": "account_789", "asset": "usd" }, "status": "active", "metadata": { "customer_id": "cust_789", "reference": "order-12345" } } ``` Use the list endpoint to retrieve all deposit destinations. - name: End User Account Management x-audience: public x-slo-tier: tier: ga description: >- The End User Account Management APIs enable developers to manage the accounts belonging to their end users. End user accounts are typically created by end users themselves when they sign in to the developer's application via the CDP Web SDK. However, developers also have the option of creating end user accounts on behalf of their end users. Critically, developers do not have the ability to sign transactions or messages on behalf of the end user; only end users can do this. End User Account Management APIs are accessed by the developer's servers and authenticated by the developer's CDP API key. - name: End User Accounts x-audience: public x-slo-tier: tier: ga description: >- The End User Accounts APIs enable end users to directly create, manage, and use their accounts. They are typically accessed via the CDP Web SDK, which handles end-user authentication and Temporary Wallet Secret management on behalf of the developer. The End User Accounts APIs offer end users full control over their accounts, including the ability to sign transactions and messages, and to export their accounts' private keys. ## Delegated Signing Delegated signing allows developers to sign and send transactions on behalf of an end user without requiring the end user to be present at signing time. This is useful for background operations, automated workflows, and scenarios where the developer's server needs to act on the end user's behalf. To use delegated signing, the end user must first create a short-lived **delegation grant** by authenticating with their access token and Temporary Wallet Secret. The grant specifies an `expiresAt` timestamp that defines how long the developer is authorized to sign on the end user's behalf. Once a delegation grant is active, the developer's server can use its CDP API key to perform signing operations for that end user. The delegation middleware transparently validates that an active (non-expired, non-revoked) grant exists for the `{project, user}` pair before allowing the operation to proceed. **Grant lifecycle:** - Delegation grants are scoped to a single project and end user pair. - Grants are time-bounded by the `expiresAt` timestamp and are automatically cleaned up after expiration. - Grants can be revoked early by either the end user (using their access token and TWS) or the developer (using their API key), via the `RevokeDelegationForEndUser` endpoint. - Only one active grant can exist per `{project, user}` pair at a given time. - name: EVM Accounts x-audience: public x-slo-tier: tier: ga description: >- The EVM Account APIs enable you to create and use accounts across blockchains that are compatible with the Ethereum Virtual Machine (EVM). An **account** is a private/public key pair that is used to sign transactions and messages. The private key is generated and used only in CDP's Trusted Execution Environment (TEE), and never exposed to Coinbase or the developer. An EVM account is identified by its **address**, which is a 0x-prefixed hexadecimal string. The same address can be used across multiple EVM networks. Accounts can optionally be assigned an **account name** at creation time for easier identification in subsequent API calls. EVM account names must be globally unique across all EVM accounts in the developer's CDP Project. ## Authentication The EVM Account API uses two layers of authentication to ensure the security of your accounts' private keys: - **CDP Secret API Key**: This key is used to authenticate all requests to the entire suite of REST APIs offered on Coinbase Developer Platform. - **Wallet Secret**: This secret is used specifically to authenticate sensitive wallet operations to `POST` and `DELETE` endpoints in the EVM and Solana Account APIs. To learn more about creating and using these keys, visit our [Authentication docs](https://docs.cdp.coinbase.com/api-reference/v2/authentication). **Use our SDK** The [CDP SDK](https://github.com/coinbase/cdp-sdk) automatically authenticates requests using your CDP Secret API Key and Wallet Secret. Use the CDP SDK for a more convenient access to our APIs. - name: EVM Smart Accounts x-audience: public x-slo-tier: tier: ga description: >- The EVM Smart Account APIs enable you to create and manage Smart Account wallets across EVM-compatible blockchains. A **Smart Account** is an EVM account that enables enhanced functionality such as account abstraction, batched transactions, and gas sponsorship through [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337). Smart Accounts allow users to create and manage "user operations" instead of traditional EVM transactions. Smart Accounts are identified by their **address**, which is a 0x-prefixed hexadecimal string. Smart Accounts can be assigned an optional **name** at creation time for easier identification in subsequent API calls. A Smart Account has a single owner, which is another EVM Account which signs the Smart Account's transactions. The owner can be a CDP EVM account, or an account managed solely by the developer. - name: EVM Swaps x-audience: public x-slo-tier: tier: beta description: >- A swap refers to the act of exchanging one token for another. The EVM Swap APIs enable you to create and manage swaps. A swap process involves: 1. A user approves token spending via smart contract. 2. The smart contract determines the exchange rate and facilitates the swap between the two tokens. 3. The transaction is completed atomically and the tokens are transferred to the user's wallet. The Swap API supports: - **Getting a price**: Estimate the amount of tokens you will receive for a given amount of exchanged tokens. - **Creating a swap quote**: Return a swap transaction payload that you can use to sign and submit in order to execute the swap. For the easiest experience creating, signing, and submitting a swap, we recommend using the [CDP SDK](https://github.com/coinbase/cdp-sdk/). - [Python SDK examples](https://github.com/coinbase/cdp-sdk/tree/main/python#evm-swaps) - [TypeScript SDK examples](https://github.com/coinbase/cdp-sdk/tree/main/typescript#evm-swaps) To read more about using the EVM Swap APIs, please see our [Swap API docs](https://docs.cdp.coinbase.com/swaps/docs/welcome). - name: EVM Token Balances x-audience: public x-slo-tier: tier: ga description: >- The EVM Token Balances APIs enable you to retrieve the balances of EVM addresses. This includes tokens (i.e. ERC-20s) and the native gas token of the network. ## Denomination - 'amount' is denominated in the smallest indivisible unit of the token. For ETH, the smallest indivisible unit is Wei (10^-18 ETH). For ERC-20s, the smallest unit is the unit returned from `function totalSupply() public view returns (uint256)`. - 'decimals' is the exponential value N that satisfies the equation `amount * 10^-N = standard_denomination`. The standard denomination is the most commonly used denomination for the token. - In the case of the native gas token, `decimals` is defined via convention. As an example, for ETH of Ethereum mainnet, the standard denomination is 10^-18 the smallest denomination (Wei). As such, for ETH on Ethereum mainnet, `decimals` is 18. - In the case of ERC-20 tokens, `decimals` is defined via configuration. `decimals` will be the number returned by `function decimals() public view returns (uint8)` on the underlying token contract. - name: Faucets x-audience: public x-slo-tier: tier: ga description: >- The Faucet APIs enable you to request funds on supported test networks. Faucets are for testing purposes and make development easier by providing a source of funds. - name: Onchain Data x-audience: public x-slo-tier: tier: ga description: >- Query and analyze blockchain data with high performance and reliability. Features include real-time token balances, token discovery, and transaction history with freshness, accuracy, and completeness like never before. - name: Onramp x-audience: public x-slo-tier: tier: ga description: >- The v2 Onramp APIs are an evolution of our [v1 APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/), designed to make the fiat-to-crypto experience feel native to your applications for higher conversion and less friction. These APIs only cover a subset of Coinbase Onramp functionality as described below, for all other use cases please refer to our [v1 APIs](https://docs.cdp.coinbase.com/api-reference/rest-api/onramp-offramp/). ## Supported Use Cases #### Apple Pay Onramp This use case allows you to offer an Apple Pay onramp experience with debit cards in your app without users needing to create or log into a Coinbase account. Our API returns a `paymentLink` URL that renders an Apple Pay button for you to load in a webview or iframe in your app, making the onramp experience feel native to your application. Refer to our [detailed integration guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/apple-pay-onramp-api) for more information on the limitations and requirements of this use case. See our [onramp mobile demo app](https://github.com/coinbase/onramp-demo-mobile) for a reference implementation. #### Hosted UI Onramp This use case enables you to offer a full-featured onramp experience by redirecting users to a Coinbase-hosted page where they can choose to log into their existing Coinbase account or proceed as a guest. The Onramp Session API generates secure, single-use Onramp URLs with customizable parameters, allowing you to control available payment methods, preset transaction amounts, and cryptocurrencies for a tailored user experience. Refer to our [guide](https://docs.cdp.coinbase.com/onramp-&-offramp/onramp-apis/generating-onramp-url) for implementation details and customization options for this use case. - name: Payment Methods x-audience: public x-slo-tier: tier: beta description: >- The Payment Methods APIs enable you to create and manage payment methods for accounts. Payment methods represent ways to send and receive payments, such as ACH transfers and Fedwire transfers. These APIs allow you to create, list, and retrieve payment method details for use in payment transfers and transactions. - name: Policy Engine x-audience: public x-slo-tier: tier: ga description: >- The Policy Engine APIs evaluate policies (a set of rules) to govern the behavior of accounts or projects, such as enforce allowlists and denylists. - A **policy** is a collection of `rules` with defined criteria. - Each **rule** contains a specified `action`, `operation`, and `criteria`: - An `action` can either `accept` or `reject` a transaction if the criteria in the rule are met. - `criteria` is an array of logical expressions. All parameters must evaluate to true for the action to be applied. - An `operation` corresponds to a CDP v2 API: - `signEvmTransaction` or `signSolTransaction` for signing transactions (to set a transaction limit). - `sendEvmTransaction` for signing a transaction, and sending it to a supported network. - `signEvmHash` for signing an arbitrary 32 byte hash. - `signEvmMessage` for signing an [EIP-191](https://eips.ethereum.org/EIPS/eip-191) message. - `prepareUserOperation` for preparing user operations on a smart account. - `sendUserOperation` for sending user operations using a smart account. - `signEndUserEvmTransaction` or `signEndUserSolTransaction` for signing end user transactions (to set a transaction limit). - `sendEndUserEvmTransaction` for signing an end user transaction, and sending it to a supported EVM network. - `sendEndUserSolTransaction` for signing an end user transaction, and sending it to a supported Solana network. - `signEndUserEvmMessage` for signing an end user [EIP-191](https://eips.ethereum.org/EIPS/eip-191) message. - `signEndUserEvmTypedData` for signing end user [EIP-712](https://eips.ethereum.org/EIPS/eip-712) typed data. - `signEndUserSolMessage` for signing an end user Solana message. - A **rule** indicates how an operation should behave, specifying whether a request with defined criteria should be accepted or rejected. ## Policy Scope Policies can be applied at the project and/or account level: - **Project-level policy**: A `project`-level policy applies to all accounts in a CDP Project. Only one project-level policy can be applied to accounts within a CDP Project at any given time. - **Account-level policy**: An `account`-level policy applies to one or more accounts. An account can have at most one account-level policy at any given time. Thus, a single account can be assigned at most two policies at any given time: one project-level policy and one account-level policy. **Note:** End user operation rules (e.g., `signEndUserEvmTransaction`, `sendEndUserSolTransaction`) currently only apply for policies with the `project` scope. Scope is specified in the `scope` field of a policy: ```json { "description": "Project-level policy", "scope": "account", ... ``` ## Policy Evaluation **Project-level policies** are evaluated first, followed by **account-level policies**. The Policy Engine will process the request against each rule in the order it is defined within the `rules` array: 1. If the rule's `criteria` (processed as a logical **AND** operation applied to a list of independently evaluated boolean expressions) are met, `accept` or `reject` behavior is applied immediately and the engine stops further evaluation of the policy. 1. If after policy evaluation, no rule's `criteria` are met, the engine moves to processing the next policy (i.e., an `account`-level policy). 1. If no further policies exist, the request is rejected. For example, the following policy is a project-level policy with two rules. The Policy Engine will: 1. **Evaluate the first rule:** For a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 1000000000000000000 wei OR 1. **Evaluate the second rule:** if the request is a `signEvmTransaction` request, accept the request if the transaction is less than or equal to 2000000000000000000 wei AND the request is made to the address `0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE`. 1. **If the request does not meet the criteria of either rule**, the engine will move on to evaluate an `account`-level policy (if one exists). 1. Otherwise, the request is rejected. Rules are processed in the order they are defined. Once a rule applies to an operation, subsequent rules are ignored. ```json { "description": "Project-level policy", "scope": "project", "rules": [ { "action": "accept", "operation": "signEvmTransaction", "criteria": [ { "type": "ethValue", "ethValue": "1000000000000000000", "operator": "<=" } ] }, { "action": "accept", "operation": "signEvmTransaction", "criteria": [ { "type": "ethValue", "ethValue": "2000000000000000000", "operator": "<=" }, { "type": "evmAddress", "addresses": [ "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE" ], "operator": "in" } ] } ] } ``` ## Policy Application Project-level policies are applied to all accounts in a CDP Project. They will apply retroactively even if the project-level policy is created after the account was created. To disable a project-level policy, you must remove the project-level policy from the CDP Project using the `deletePolicy` operation. Account-level policies can be applied in two ways: - By specifying the `accountPolicy` field in the request body of the `createEvmAccount` and `createSolAccount` operations. - By specifying the `accountPolicy` field in the request body of the `updateEvmAccount` and `updateSolanaAccount` operations. ## Criteria The following criteria are supported: ### SignEvmTransaction Criteria #### ethValue A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field. #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. #### netUSDChange A criterion based on the USD denominated market value of assets being transferred, or exposing the sender to. The types of assets included in the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155` tokens. The sum total USD amount of assets being transferred and exposed is compared to the criterion's `changeCents` field using the `operator` field. If signing a testnet transaction, then this criterion configuration will be ignored. ### SendEvmTransaction Criteria #### ethValue A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field. #### evmNetwork A criterion based on the intended network of the transaction. The `network` field in the `sendEvmTransaction` request body is compared to the criterion's `networks` field using the `operator` field. Valid networks for this criterion include: - `base` - `base-sepolia` - `ethereum` - `ethereum-sepolia` - `avalanche` - `polygon` - `optimism` - `arbitrum` - `arbitrum-sepolia` - `world` - `world-sepolia` #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. #### netUSDChange A criterion based on the USD denominated market value of assets being transferred, or exposing the sender to. The types of assets included in the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155` tokens. The sum total USD amount of assets being transferred and exposed is compared to the criterion's `changeCents` field using the `operator` field. If sending a testnet transaction, then this criterion configuration will be ignored. ### SendUserOperation Criteria #### ethValue A criterion based on the value of the user operation. The operation's `value` fields are compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the operation. The operation's `to` fields are compared to the criterion's `addresses` field using the `operator` field. #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. ### PrepareUserOperation Criteria #### ethValue A criterion based on the value of the user operation. The operation's `value` fields are compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the user operation. The operation's `to` fields are compared to the criterion's `addresses` field using the `operator` field. #### evmNetwork A criterion based on the intended network of the user operation. The `network` field in the `prepareUserOperation` request body is compared to the criterion's `networks` field using the `operator` field. Valid networks for this criterion include: - `base-sepolia` - `base` - `arbitrum` - `optimism` - `zora` - `polygon` - `bnb` - `avalanche` - `ethereum` - `ethereum-sepolia` #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. ### SignEvmHash Criteria The `signEvmHash` operation does not accept any criteria. To prevent this operation from being executed by any account, specify a rule with `signEvmHash` as the operation, and `reject` as its action. ### SignEvmMessage Criteria #### evmMessage A criterion based on the intended message to be signed. The `match` field in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax) compliant regular expression that will be executed against the message in the API request. ### SignSolMessage Criteria #### solMessage A criterion based on the intended message to be signed. The `match` field in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax) compliant regular expression that will be executed against the message in the API request. ### SignSolTransaction Criteria #### solAddress A criterion based on the recipient addresses of the transaction. The criterion's `address` field is compared to the list of addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solValue A criterion based on the value of the transaction. The criterion's `solValue` field is compared to the transaction's `value`, which is the amount of SOL in lamports being transferred, using the `operator` field. #### splAddress A criterion based on the recipient addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### splValue A criterion based on the SPL token value of SPL token transfer instructions in the transaction. The criterion's `splValue` field is compared to the transaction instruction's `value` field, which is the amount of the SPL token being transferred, using the `operator` field. #### mintAddress A criterion based on the token mint addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solData A criterion based on Solana transaction instruction data. The criterion uses Interface Definition Language (IDL) specifications to decode and validate instruction data against specific rules. The `idls` field specifies which Solana programs to validate against (either known program names like "SystemProgram" and "TokenProgram", or custom IDL objects), and the `conditions` field defines instruction-specific validation rules including instruction names and parameter constraints. #### programId A criterion based on the program IDs of a transaction's instructions. The criterion's `programIds` field is compared to the list of program IDs in the transaction's instructions using the `operator` field. ### SendSolTransaction Criteria #### solAddress A criterion based on the recipient addresses of the transaction. The criterion's `address` field is compared to the list of addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solValue A criterion based on the value of the transaction. The criterion's `solValue` field is compared to the transaction's `value`, which is the amount of SOL in lamports being transferred, using the `operator` field. #### splAddress A criterion based on the recipient addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### splValue A criterion based on the SPL token value of SPL token transfer instructions in the transaction. The criterion's `splValue` field is compared to the transaction instruction's `value` field, which is the amount of the SPL token being transferred, using the `operator` field. #### mintAddress A criterion based on the token mint addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solData A criterion based on Solana transaction instruction data. The criterion uses Interface Definition Language (IDL) specifications to decode and validate instruction data against specific rules. The `idls` field specifies which Solana programs to validate against (either known program names like "SystemProgram" and "TokenProgram", or custom IDL objects), and the `conditions` field defines instruction-specific validation rules including instruction names and parameter constraints. #### programId A criterion based on the program IDs of a transaction's instructions. The criterion's `programIds` field is compared to the list of program IDs in the transaction's instructions using the `operator` field. #### solNetwork A criterion based on the intended network of the transaction. The `network` field in the `sendSolanaTransaction` request body is compared to the criterion's `networks` field using the `operator` field. Valid networks for this criterion include: - `solana-devnet` - `solana` ## End User Criteria for User Wallets End user criteria apply to operations performed by end users via user wallets. These criteria are only evaluated for policies with the `project` scope. The supported criterion types for each end user operation mirror their non-end-user counterparts. ### SignEndUserEvmTransaction Criteria #### ethValue A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field. #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. #### netUSDChange A criterion based on the USD denominated market value of assets being transferred, or exposing the sender to. The types of assets included in the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155` tokens. The sum total USD amount of assets being transferred and exposed is compared to the criterion's `changeCents` field using the `operator` field. If signing a testnet transaction, then this criterion configuration will be ignored. ### SendEndUserEvmTransaction Criteria #### ethValue A criterion based on the value of the transaction. The transaction's `value` field is compared to the criterion's `ethValue` field using the `operator` field. #### evmAddress A criterion based on the recipient address of the transaction. The transaction's `to` field is compared to the criterion's `addresses` field using the `operator` field. #### evmNetwork A criterion based on the intended network of the transaction. The `network` field in the `sendEndUserEvmTransaction` request body is compared to the criterion's `networks` field using the `operator` field. Valid networks for this criterion include: - `base` - `base-sepolia` - `ethereum` - `ethereum-sepolia` - `avalanche` - `polygon` - `optimism` - `arbitrum` #### evmData A criterion based on encoded transaction data that evaluates the function being called, as well as any number of arguments accessed by either name or index. Currently this criterion only supports primitive types; `string`, `bool`, `uint(8,16,32,64,256)`, `int(8,16,32,64,256)`, `address`, and both fixed and dynamic length `bytes`. #### netUSDChange A criterion based on the USD denominated market value of assets being transferred, or exposing the sender to. The types of assets included in the calculation include native assets, `ERC20`, `ERC721`, and `ERC1155` tokens. The sum total USD amount of assets being transferred and exposed is compared to the criterion's `changeCents` field using the `operator` field. If sending a testnet transaction, then this criterion configuration will be ignored. ### SignEndUserEvmMessage Criteria #### evmMessage A criterion based on the intended message to be signed. The `match` field in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax) compliant regular expression that will be executed against the message in the API request. ### SignEndUserEvmTypedData Criteria #### evmTypedDataField A criterion based on the fields of the [EIP-712](https://eips.ethereum.org/EIPS/eip-712) typed data being signed. The `types` field specifies the EIP-712 type definitions and primary type, while the `conditions` field defines validation rules for specific fields within the typed data message. Conditions can target address fields, numerical fields, or string fields, and can reference deeply nested values using dot-separated paths. #### evmTypedDataVerifyingContract A criterion based on the verifying contract address in the [EIP-712](https://eips.ethereum.org/EIPS/eip-712) domain separator. The domain's `verifyingContract` field is compared to the criterion's `addresses` field using the `operator` field. ### SignEndUserSolTransaction Criteria #### solAddress A criterion based on the recipient addresses of the transaction. The criterion's `address` field is compared to the list of addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solValue A criterion based on the value of the transaction. The criterion's `solValue` field is compared to the transaction's `value`, which is the amount of SOL in lamports being transferred, using the `operator` field. #### splAddress A criterion based on the recipient addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### splValue A criterion based on the SPL token value of SPL token transfer instructions in the transaction. The criterion's `splValue` field is compared to the transaction instruction's `value` field, which is the amount of the SPL token being transferred, using the `operator` field. #### mintAddress A criterion based on the token mint addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solData A criterion based on Solana transaction instruction data. The criterion uses Interface Definition Language (IDL) specifications to decode and validate instruction data against specific rules. The `idls` field specifies which Solana programs to validate against (either known program names like "SystemProgram" and "TokenProgram", or custom IDL objects), and the `conditions` field defines instruction-specific validation rules including instruction names and parameter constraints. #### programId A criterion based on the program IDs of a transaction's instructions. The criterion's `programIds` field is compared to the list of program IDs in the transaction's instructions using the `operator` field. ### SendEndUserSolTransaction Criteria #### solAddress A criterion based on the recipient addresses of the transaction. The criterion's `address` field is compared to the list of addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solValue A criterion based on the value of the transaction. The criterion's `solValue` field is compared to the transaction's `value`, which is the amount of SOL in lamports being transferred, using the `operator` field. #### splAddress A criterion based on the recipient addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of SPL token transfer recipient addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### splValue A criterion based on the SPL token value of SPL token transfer instructions in the transaction. The criterion's `splValue` field is compared to the transaction instruction's `value` field, which is the amount of the SPL token being transferred, using the `operator` field. #### mintAddress A criterion based on the token mint addresses of SPL token transfer instructions in the transaction. The criterion's `addresses` field is compared to the list of token mint addresses in the transaction's `accountKeys` (for legacy transactions) or `staticAccountKeys` (for V0 transactions) array using the `operator` field. #### solData A criterion based on Solana transaction instruction data. The criterion uses Interface Definition Language (IDL) specifications to decode and validate instruction data against specific rules. The `idls` field specifies which Solana programs to validate against (either known program names like "SystemProgram" and "TokenProgram", or custom IDL objects), and the `conditions` field defines instruction-specific validation rules including instruction names and parameter constraints. #### programId A criterion based on the program IDs of a transaction's instructions. The criterion's `programIds` field is compared to the list of program IDs in the transaction's instructions using the `operator` field. #### solNetwork A criterion based on the intended network of the transaction. The `network` field in the `sendEndUserSolTransaction` request body is compared to the criterion's `networks` field using the `operator` field. Valid networks for this criterion include: - `solana-devnet` - `solana` ### SignEndUserSolMessage Criteria #### solMessage A criterion based on the intended message to be signed. The `match` field in the criteria is a [RE2](https://github.com/google/re2/wiki/Syntax) compliant regular expression that will be executed against the message in the API request. ## Restricting Contract Interactions on Ethereum Smart contract function restrictions serve as a critical security and governance mechanism in decentralized applications, allowing developers and organizations to implement fine-grained access controls over their protocol interactions. One of the primary use cases for function restrictions is protecting high-risk operations from unauthorized access such as: - Fund transfers - Contract upgrades - Parameter modifications - Emergency pauses Policy Engine supports such restrictions that evaluate against transaction data with the `evmData` criterion for the `signEvmTransaction`, and `sendEvmTransaction` operations. ## Examples ### USD Limits The following example demonstrates a policy that only allows transactions to transfer, or expose the sender to, less than $100.00 worth of assets at a time. This USD denominated amount includes native assets, `ERC20`, `ERC721`, and `ERC1155` tokens calculated using current market prices. ```json { "scope": "account", "description": "Reject assets out over 100 USD", "rules": [ { "action": "reject", "operation": "sendEvmTransaction", "criteria": [ { "type": "netUSDChange", "changeCents": 10000, "operator": ">", }, ], }, { "action": "reject", "operation": "signEvmTransaction", "criteria": [ { "type": "netUSDChange", "changeCents": 10000, "operator": ">", }, ], }, ], } ``` ### Limiting USDC Spend This policy restricts USDC transactions on the Base network to transfers of 10,000 tokens or less. It applies to both signing and sending transactions to the USDC contract address, using the ERC20 ABI to validate that only `transfer` function calls with a `value` parameter under the specified limit are permitted. ```json { "description": "Limit USDC Spend", "scope": "account", "rules": [ { "action": "accept", "operation": "sendEvmTransaction", "criteria": [ { "type": "evmNetwork", "networks": ["base"], "operator": "in" }, { "type": "evmAddress", "addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"], "operator": "in" }, { "type": "evmData", "abi": "erc20", "conditions": [ { "function": "transfer", "params": [ { "name": "value", "operator": "<=", "value": "10000" } ] } ] } ] }, { "action": "accept", "operation": "signEvmTransaction", "criteria": [ { "type": "evmAddress", "addresses": ["0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"], "operator": "in" }, { "type": "evmData", "abi": "erc20", "conditions": [ { "function": "transfer", "params": [ { "name": "value", "operator": "<=", "value": "10000" } ] } ] } ] } ] } ```. - name: Solana Accounts x-audience: public x-slo-tier: tier: ga description: >- The Solana Account APIs enable you to create and use Solana accounts across SVM-compatible blockchains. An **account** is a private/public key pair that is used to sign transactions and messages. The private key is generated and used only in CDP's Trusted Execution Environment (TEE), and never exposed to Coinbase or the developer. A Solana account is identified by its **address**, which is a base-58 encoded string. Accounts can optionally be assigned an **account name** at creation time for easier identification in subsequent API calls. Solana account names must be globally unique across all Solana accounts in the developer's CDP Project. ## Authentication The Solana Account APIs use two layers of authentication to ensure the security of your accounts' private keys: - **CDP Secret API Key**: This key is used to authenticate all requests to the entire suite of REST APIs offered on Coinbase Developer Platform. - **Wallet Secret**: This secret is used specifically to authenticate sensitive wallet operations to `POST` and `DELETE` endpoints in the EVM and Solana Account APIs. To learn more about creating and using these keys, visit our [Authentication docs](https://docs.cdp.coinbase.com/api-reference/v2/authentication). **Use our SDK** The [CDP SDK](https://github.com/coinbase/cdp-sdk) automatically authenticates requests using your CDP Secret API Key and Wallet Secret. Use the CDP SDK for a more convenient access to our APIs. - name: Solana Token Balances x-audience: public x-slo-tier: tier: ga description: >- The Solana Token Balances APIs enable you to retrieve the balances of Solana addresses. This includes SPL tokens and the native SOL token of the network. ## Denomination - 'amount' is denominated in the smallest indivisible unit of the token. For SOL, the smallest indivisible unit is lamports (10^-9 SOL). For SPL tokens, the smallest unit is defined by the token's decimals configuration. - 'decimals' is the exponential value N that satisfies the equation `amount * 10^-N = standard_denomination`. The standard denomination is the most commonly used denomination for the token. - For native SOL, `decimals` is 9 (1 SOL = 10^9 lamports). - For SPL tokens, `decimals` is defined in the token's mint configuration. - name: SQL API x-audience: public x-slo-tier: tier: ga description: >- The SQL API enables you to write performant, high-freshness, and endlessly flexible SQL queries against onchain data. - name: Transfers x-audience: public x-slo-tier: tier: beta description: >- **Transfers** represent both the request and execution of fund transfers from a source to a target. They provide upfront fee quotes and track the complete lifecycle from initiation through completion, failure, or reversal. ## Fee Quotes Every transfer provides a comprehensive fee quote in the `fees` array. This allows you to show users exactly what they'll pay before any money moves. To review fees before execution: 1. Create a transfer with `execute: false` 2. Review the `fees` array in the response 3. Call `POST /transfers/{transferId}/execute` when ready to proceed For automatic execution without fee review, create a transfer with `execute: true`. **Fee Expiration**: Fee quotes are valid for a limited time (typically 10-15 minutes from creation). The `expiresAt` field shows exactly when the fee quote will expire. If you don't execute before this time, you'll need to create a new transfer to get updated fees. ## Fees Transfer fees vary by source, target, amount and transfer type: * **Bank fees** - Traditional banking fees for depositing funds (e.g., $15.00 wire transfer fee) * **Conversion fees** - Fees for exchanging between different assets * **Network fees** - Onchain transaction costs to complete the transfer (e.g., ETH gas fees) All fees are disclosed upfront in the `fees` array when you create a transfer. ## Transfer Lifecycle When you create a transfer, it will be in one of these statuses that determine what action you need to take: * **`quoted`** - Transfer is ready but requires manual execution via the `/execute` endpoint * **`processing`** - Transfer is being executed (no action needed - poll for completion) * **`completed`** - Transfer completed successfully * **`failed`** - Transfer failed (see `failureReason` for details) ## Execution Control * **`execute: true`**: Transfer will automatically attempt to execute * **`execute: false`**: Transfer will be created in `quoted` status and you must call the `/execute` endpoint. Use this to obtain a fee quote or validate a transfer destination before deciding whether to execute the Transfer. ## Sources and Targets * A **source** can be an Account or a Payment Method * A **target** can be an Account, Payment Method, Onchain Address, or Email Address ## Transfer Execution When a transfer reaches `completed` status, it contains the final execution details that delivered funds to the target and completion timestamps. ## Failure Reasons When a transfer fails, the `failureReason` field provides a human-readable description of what went wrong. Common failure reasons include: * "Insufficient balance to complete this transfer." * "The recipient address is invalid for the selected network." * "The recipient address failed security validation checks." * "Unable to send to this recipient." Failure reason is only present when the transfer's status is `failed`. - name: Wallet Webhooks x-audience: public x-slo-tier: tier: ga description: >- The `wallet.activity.*` webhook payloads describe wallet activity, transaction, delegation, and signing events emitted by CDP. - name: Webhooks x-audience: public x-slo-tier: tier: ga description: >- Subscribe to real-time events across CDP products. Monitor onchain activity on Base mainnet, track onramp/offramp transactions, and receive instant notifications for wallet events. - name: x402 Facilitator x-audience: public x-slo-tier: tier: beta description: >- The x402 payment protocol is an HTTP-based payment protocol that enables developers running resource servers to accept payments from users using a variety of payment methods. For more details on the x402 payment protocol, please see the [x402 specification](https://www.x402.org/). The x402 Facilitator APIs enable you to facilitate payments using the x402 payment protocol by exposing two APIs: - `POST /v2/x402/verify`: Verify a payment with a supported scheme and network. - `POST /v2/x402/settle`: Settle a payment with a supported scheme and network. paths: /v2/solana/accounts: post: tags: - Solana Accounts summary: Create Solana account description: Creates a new Solana account. operationId: createSolanaAccount parameters: - $ref: '#/components/parameters/XWalletAuth' - $ref: '#/components/parameters/IdempotencyKey' requestBody: required: false content: application/json: schema: type: object properties: name: type: string description: >- An optional name for the account. Account names can consist of alphanumeric characters and hyphens, and be between 2 and 36 characters long. Account names must be unique across all Solana accounts in the developer's CDP Project. example: my-wallet pattern: ^[A-Za-z0-9][A-Za-z0-9-]{0,34}[A-Za-z0-9]$ accountPolicy: type: string x-audience: public description: The ID of the account-level policy to apply to the account. pattern: >- ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$ example: 123e4567-e89b-12d3-a456-426614174000 responses: '201': description: Successfully created Solana account. content: application/json: schema: $ref: '#/components/schemas/SolanaAccount' '400': description: Invalid request. content: application/json: schema: $ref: '#/components/schemas/Error' examples: invalid_request: value: errorType: invalid_request errorMessage: >- Project has no secret. Please register a secret with the project. '401': description: Unauthorized. content: application/json: schema: $ref: '#/components/schemas/Error' examples: unauthorized: value: errorType: unauthorized errorMessage: Wallet authentication error. '402': $ref: '#/components/responses/PaymentMethodRequiredError' '409': description: Resource already exists. content: application/json: schema: $ref: '#/components/schemas/Error' examples: already_exists: value: errorType: already_exists errorMessage: Solana account with the given name already exists. '422': $ref: '#/components/responses/IdempotencyError' '500': $ref: '#/components/responses/InternalServerError' '502': $ref: '#/components/responses/BadGatewayError' '503': $ref: '#/components/responses/ServiceUnavailableError' security: - apiKeyAuth: [] components: parameters: XWalletAuth: name: X-Wallet-Auth in: header required: true description: > A JWT signed using your Wallet Secret, encoded in base64. Refer to the [Generate Wallet Token](https://docs.cdp.coinbase.com/api-reference/v2/authentication#2-generate-wallet-token) section of our Authentication docs for more details on how to generate your Wallet Token. schema: type: string example: >- eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIiwiZXhwIjoxNzAxOTgwMDAwfQ.HWvMTKmCCTxHaxjvZyLaC6UQ6TV3ErTDWBf7zmdH0Lw IdempotencyKey: name: X-Idempotency-Key in: header required: false description: > An optional string request header for making requests safely retryable. When included, duplicate requests with the same key will return identical responses. Refer to our [Idempotency docs](https://docs.cdp.coinbase.com/api-reference/v2/idempotency) for more information on using idempotency keys. schema: type: string maxLength: 128 minLength: 1 example: 8e03978e-40d5-43e8-bc93-6894a57f9324 schemas: SolanaAccount: type: object properties: address: type: string pattern: ^[1-9A-HJ-NP-Za-km-z]{32,44}$ description: The base58 encoded Solana address. example: HpabPRRCFbBKSuJr5PdkVvQc85FyxyTWkFM2obBRSvHT name: type: string description: >- An optional name for the account. Account names can consist of alphanumeric characters and hyphens, and be between 2 and 36 characters long. Account names are guaranteed to be unique across all Solana accounts in the developer's CDP Project. example: my-account pattern: ^[A-Za-z0-9][A-Za-z0-9-]{0,34}[A-Za-z0-9]$ policies: type: array x-audience: public description: >- The list of policy IDs that apply to the account. This will include both the project-level policy and the account-level policy, if one exists. items: type: string pattern: >- ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$ example: - 123e4567-e89b-12d3-a456-426614174000 createdAt: type: string description: The ISO 8601 UTC timestamp at which the account was created. example: '2025-03-25T12:00:00Z' format: date-time updatedAt: type: string description: The ISO 8601 UTC timestamp at which the account was last updated. example: '2025-03-26T12:00:00Z' format: date-time required: - address Error: description: >- An error response including the code for the type of error and a human-readable message describing the error. type: object properties: errorType: $ref: '#/components/schemas/ErrorType' errorMessage: description: The error message. type: string example: Unable to create EVM account correlationId: description: >- A unique identifier for the request that generated the error. This can be used to help debug issues with the API. type: string example: 41deb8d59a9dc9a7-IAD errorLink: allOf: - $ref: '#/components/schemas/Url' description: A link to the corresponding error documentation. example: >- https://docs.cdp.coinbase.com/api-reference/v2/errors#invalid-request unauthorizedCapabilities: description: > The capability code(s) that were not authorized for the customer on this request. Present only when `errorType` is `customer_not_authorized`; absent for every other error type. Use this list to render onboarding UX for the listed capabilities, or fetch `GET /v2/customers/{customerId}` and inspect each entry's `status` / `requirements` to discover what (if anything) can be submitted to resolve the block. type: array items: $ref: '#/components/schemas/CapabilityName' required: - errorType - errorMessage example: errorType: invalid_request errorMessage: Invalid request. correlationId: 41deb8d59a9dc9a7-IAD errorLink: https://docs.cdp.coinbase.com/api-reference/v2/errors#invalid-request ErrorType: description: >- The code that indicates the type of error that occurred. These error codes can be used to determine how to handle the error. type: string example: invalid_request enum: - already_exists - authorization_expired - bad_gateway - capture_expired - client_closed_request - customer_not_authorized - endpoint_unavailable - faucet_limit_exceeded - forbidden - idempotency_error - internal_server_error - invalid_request - invalid_sql_query - invalid_signature - malformed_transaction - not_found - payment_method_required - payment_required - settlement_failed - rate_limit_exceeded - request_canceled - service_unavailable - timed_out - unauthorized - unsupported_tos_language - policy_violation - policy_in_use - account_limit_exceeded - network_not_tradable - guest_permission_denied - guest_region_forbidden - guest_transaction_limit - guest_transaction_count - phone_number_verification_expired - otp_verification_code_invalid - otp_verification_destination_mismatch - otp_verification_expired - otp_verification_invalid - otp_verification_not_found - otp_verification_required - document_verification_failed - recipient_allowlist_violation - recipient_allowlist_pending - refund_expired - travel_rules_recipient_violation - source_account_invalid - target_account_invalid - source_account_not_found - target_account_not_found - source_asset_not_supported - target_asset_not_supported - target_email_invalid - target_onchain_address_invalid - transfer_amount_invalid - transfer_asset_not_supported - transfer_quote_expired - insufficient_balance - metadata_too_many_entries - metadata_key_too_long - metadata_value_too_long - travel_rules_field_missing - asset_mismatch - mfa_already_enrolled - mfa_invalid_code - mfa_flow_expired - mfa_required - mfa_not_enrolled - order_quote_expired - order_already_filled - order_already_canceled - account_not_ready - insufficient_liquidity - insufficient_allowance - transaction_simulation_failed - delegation_not_found - delegation_expired - delegation_revoked - delegation_not_authorized - delegation_not_enabled - network_mismatch - already_enabled - payment_session_already_canceled - payment_session_already_authorized - payment_session_action_pending - no_capturable_balance - no_voidable_balance - no_refundable_balance - entity_not_configured_for_payment_acceptance - daily_transaction_limit_exceeded - daily_amount_limit_exceeded - stale_attestation - moderation_rejected x-error-instructions: already_exists: >- This error occurs when trying to create a resource that already exists. **Steps to resolve:** 1. Check if the resource exists before creation 2. Use GET endpoints to verify resource state 3. Use unique identifiers/names for resources authorization_expired: >- Returned when an authorization attempt is made after the payment session's authorization deadline has passed. Create a new payment session with a later authorization deadline. bad_gateway: >- This error occurs when the CDP API is unable to connect to the backend service. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - The timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. capture_expired: >- Returned when a capture attempt is made after the payment session's capture deadline has passed. The payment session can no longer be captured. client_closed_request: >- This error occurs when the client closes the connection before the server can send a response. **Common causes:** - The client timed out waiting for the server response - The client application was terminated during a pending request - Network interruption caused the client connection to drop **Steps to resolve:** 1. Increase client-side timeout settings if applicable 2. Implement retry logic with exponential backoff for long-running queries 3. Consider optimizing the request to reduce server processing time endpoint_unavailable: >- This error occurs when a specific endpoint has been temporarily disabled by an operator (e.g. a kill switch). The CDP API as a whole is still healthy; only this endpoint is unavailable. Distinct from `service_unavailable`, which indicates the API itself is down. Re-enabling is a manual operator action, so the endpoint may remain unavailable for an extended period. **Steps to resolve:** 1. Check the [CDP status page](https://cdpstatus.coinbase.com/) for an active incident. 2. If persistent, contact CDP support with: - The timestamp of the error - Request details faucet_limit_exceeded: >- This error occurs when you've exceeded the faucet request limits. **Steps to resolve:** 1. Wait for the time window to reset 2. Use funds more efficiently in your testing For more information on faucet limits, please visit the [EVM Faucet endpoint](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/faucets/request-funds-on-evm-test-networks) or the [Solana Faucet endpoint](https://docs.cdp.coinbase.com/api-reference/v2/rest-api/faucets/request-funds-on-solana-devnet). customer_not_authorized: >- This error occurs when the customer is not currently authorized for one or more capabilities required to perform the requested action. This can happen at any point in the customer's lifecycle and may or may not be resolvable by the developer. The response includes an `unauthorizedCapabilities` field listing the capability code(s) that were not authorized on this request. **Steps to resolve:** 1. Fetch the customer with `GET /v2/customers/{customerId}` and inspect the `requirements` field. If `requirements.due` is non-empty, submit the listed fields via `PUT /v2/customers/{customerId}` and retry. 2. If `requirements.due` is empty, no further action is available — the customer is not currently eligible for this action. forbidden: >- This error occurs when you don't have permission to access the resource. **Steps to resolve:** 1. Verify your permissions to access the resource 2. Ensure that you are the owner of the requested resource idempotency_error: >- This error occurs when an idempotency key is reused with different parameters. **Steps to resolve:** 1. Generate a new UUID v4 for each unique request 2. Only reuse idempotency keys for exact request duplicates 3. Track used keys within your application **Example idempotency key implementation:** ```typescript lines wrap import { v4 as uuidv4 } from 'uuid'; function createIdempotencyKey() { return uuidv4(); } ``` internal_server_error: >- This indicates an unexpected error that occurred on the CDP servers. **Important**: If you encounter this error, please note that your operation's status should be treated as unknown by your application, as it could have been a success within the CDP back-end. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - Your correlation ID - Timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. invalid_request: >- This error occurs when the request is malformed or contains invalid data, including issues with the request body, query parameters, path parameters, or headers. **Steps to resolve:** 1. Check all required fields and parameters are present 2. Ensure request body (if applicable) follows the correct schema 3. Verify all parameter formats match the API specification: - Query parameters - Path parameters - Request headers 4. Validate any addresses, IDs, or other formatted strings meet requirements **Common validation issues:** - Missing required parameters - Invalid parameter types or formats - Malformed JSON in request body - Invalid enum values #### Transfer-specific validation errors The following transfer validation scenarios return `errorType: "invalid_request"`. Use the `errorMessage` field to identify the specific case. | Scenario | Example `errorMessage` | |----------|----------------------| | Source account ID is malformed | `"source is invalid."` | | Target account ID is malformed | `"target is invalid."` | | Source account does not exist | `"source not found."` | | Target account does not exist | `"target not found."` | | Asset not supported at source | `"source is not supported."` | | Asset not supported at target | `"target is not supported."` | | Target email address is malformed | `"target has an invalid email format."` | | Target onchain address is invalid for network | `"The recipient address is invalid for the selected network."` | | Asset not supported for this transfer route | `"Transfer asset pair is not supported."` | | Insufficient balance | `"Insufficient funds to complete this transfer."` | | Asset mismatch between request fields | `"Currency mismatch in request."` | | Metadata has too many keys | `"Metadata has too many keys. Up to 10 key/value pairs are permitted."` | | Metadata key exceeds length limit | `"Metadata key is too long. Each key must be less than or equal to 40 characters."` | | Metadata value exceeds length limit | `"Metadata value is too long. Each value must be less than or equal to 500 characters."` | | Travel rule fields missing | `"Travel rule information is incomplete. Missing fields: ..."` | | Recipient address not in account allowlist | `"Your coinbase account allowlist does not include this address. Please update your allowlist at https://www.coinbase.com/settings/allowlist"` | invalid_sql_query: |- This error occurs when the SQL query is invalid or not allowed. **Common causes:** - Using non-SELECT SQL statements (INSERT, UPDATE, DELETE, etc.) - Invalid table or column names - Syntax errors in SQL query - Query exceeds character limit - Too many JOIN operations invalid_signature: >- This error occurs when the signature provided for the given user operation is invalid. **Steps to resolve:** 1. Verify the signature was generated by the correct owner account 2. Ensure the signature corresponds to the exact user operation hash 3. Check that the signature format matches the expected format 4. Confirm you're using the correct network for the Smart Account **Common causes:** - Using wrong owner account to sign - Signing modified/incorrect user operation data - Malformed signature encoding - Network mismatch between signature and broadcast malformed_transaction: >- This error occurs when the transaction data provided is not properly formatted or is invalid. **Steps to resolve:** 1. Verify transaction encoding: - **EVM networks**: Check RLP encoding is correct - **Solana**: Validate base64 encoding 2. Ensure all required transaction fields are present 3. Validate transaction parameters are within acceptable ranges 4. Check that the transaction type is supported on the target network (see our [Supported Networks](https://docs.cdp.coinbase.com/get-started/supported-networks) page for more details) **Common causes:** - Invalid hex encoding for EVM transactions - Missing required transaction fields - Incorrect parameter formats - Unsupported transaction types - Network-specific transaction format mismatches not_found: >- This error occurs when the resource specified in your request doesn't exist or you don't have access to it. **Steps to resolve:** 1. Verify the resource ID/address/account exists 2. Check your permissions to access the resource 3. Ensure you're using the correct network/environment 4. Confirm the resource hasn't been deleted **Common causes:** - Mistyped addresses - Accessing resources from the wrong CDP project - Resource was deleted or hasn't been created yet payment_method_required: >- This error occurs when a payment method is required to complete the requested operation but none is configured or available. **Steps to resolve:** 1. Add a valid payment method to your account using the [CDP Portal](https://portal.cdp.coinbase.com) 2. Ensure your payment method is valid and not expired **Common causes:** - No payment method configured on the account - Payment method is expired payment_required: >- This error occurs when an x402 payment is required to access the requested resource. **Steps to resolve:** 1. Include a valid x402 payment header in your request 2. Ensure the payment meets the resource's pricing requirements settlement_failed: >- This error occurs when an x402 payment was verified but settlement on-chain failed. **Steps to resolve:** 1. Retry the request with a new payment 2. Ensure the payment asset has sufficient balance for settlement rate_limit_exceeded: |- This error occurs when you've exceeded the API rate limits. **Steps to resolve:** 1. Implement exponential backoff 2. Cache responses where possible 3. Wait for rate limit window to reset **Best practices:** ```typescript lines wrap async function withRetry(fn: () => Promise) { let delay = 1000; while (true) { try { return await fn(); } catch (e) { if (e.errorType === "rate_limit_exceeded") { await sleep(delay); delay *= 2; continue; } throw e; } } } ``` request_canceled: >- This error occurs when the client cancels an in-progress request before it completes. **Steps to resolve:** 1. Check client-side timeout configurations 2. Review request cancellation logic in your code 3. Consider increasing timeout thresholds for long-running operations 4. Implement request tracking to identify premature cancellations **Best practices:** ```typescript lines wrap async function withTimeout(promise: Promise, timeoutMs: number): Promise { const timeout = new Promise((_, reject) => { setTimeout(() => { reject(new Error("Operation timed out")); }, timeoutMs); }); try { return await Promise.race([promise, timeout]); } catch (error) { // Handle timeout or cancellation throw error; } } ``` service_unavailable: >- This error occurs when the CDP API is temporarily unable to handle requests due to maintenance or high load. **Steps to resolve:** 1. Retry your request after a short delay 2. If persistent, contact CDP support with: - The timestamp of the error - Request details 3. Consider implementing retry logic with an exponential backoff **Note:** These errors are automatically logged and monitored by CDP. timed_out: >- This error occurs when a request exceeds the maximum allowed processing time. **Steps to resolve:** 1. Break down large requests into smaller chunks (if applicable) 2. Implement retry logic with exponential backoff 3. Use streaming endpoints for large data sets **Example retry implementation:** ```typescript lines wrap async function withRetryAndTimeout( operation: () => Promise, maxRetries = 3, timeout = 30000, ): Promise { let attempts = 0; while (attempts < maxRetries) { try { return await Promise.race([ operation(), new Promise((_, reject) => setTimeout(() => reject(new Error("Timeout")), timeout) ), ]); } catch (error) { attempts++; if (attempts === maxRetries) throw error; // Exponential backoff await new Promise(resolve => setTimeout(resolve, Math.pow(2, attempts) * 1000) ); } } throw new Error("Max retries exceeded"); } ``` unauthorized: |- This error occurs when authentication fails. **Steps to resolve:** 1. Verify your CDP API credentials: - Check that your API key is valid - Check that your Wallet Secret is properly configured 2. Validate JWT token: - Not expired - Properly signed - Contains required claims 3. Check request headers: - Authorization header present - X-Wallet-Auth header included when required **Security note:** Never share your Wallet Secret or API keys. unsupported_tos_language: >- A submitted Terms of Service acceptance used a `language` that is not published for the referenced `versionId`. **Steps to resolve:** 1. Read `Customer.requirements.tos.tosVersions[]` and find the entry whose `versionId` matches your acceptance. 2. Choose a `language` from that entry's `languages` list (BCP 47 tags). 3. Retry with `tosAcceptances[].language` set to a supported tag. policy_in_use: >- This error occurs when trying to delete a Policy that is currently in use by at least one project or account. **Steps to resolve:** 1. Update project or accounts to remove references to the Policy in question. 2. Retry your delete request. network_not_tradable: >- This error occurs when the selected asset cannot be purchased on the selected network in the user's location. **Steps to resolve:** 1. Verify the asset is tradable on the selected network 2. Check the user's location to ensure it is allowed to purchase the asset on the selected network **Common causes:** - Users in NY are not allowed to purchase USDC on any network other than Ethereum guest_permission_denied: >- This error occurs when the user is not allowed to complete onramp transactions as a guest. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. guest_region_forbidden: >- This error occurs when guest onramp transactions are not allowed in the user's region. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. guest_transaction_limit: >- This error occurs when the user has reached the weekly guest onramp transaction limit. **Steps to resolve:** 1. Inform the user they have reached their weekly limit and will have to wait until next week. guest_transaction_count: >- This error occurs when the user has reached the lifetime guest onramp transaction count limit. **Steps to resolve:** 1. Redirect the user to create a Coinbase account to buy and send crypto. phone_number_verification_expired: >- This error occurs when the user's phone number verification has expired. Use of guest Onramp requires the user's phone number to be verified every 60 days. **Steps to resolve:** 1. Re-verify the user's phone number via OTP. 2. Retry the request with the phoneNumberVerifiedAt field set to new verification timestamp. otp_verification_destination_mismatch: >- The `phoneNumber` or `email` on the order does not match the `destination` that was verified. **Steps to resolve:** 1. Ensure the `phoneNumber` or `email` field on the order matches the `destination` used during verification. 2. If the value changed, complete a new verification for the updated phone number or email. otp_verification_expired: >- The `smsVerificationId` or `emailVerificationId` provided has expired. Verification IDs are valid for 60 days after successful OTP submission. **Steps to resolve:** 1. Complete a new verification flow for the user. 2. Use the new verification ID when creating orders. otp_verification_code_invalid: >- This error occurs when the OTP code submitted to complete a verification is incorrect or has expired (the 10-minute OTP window has elapsed). **Steps to resolve:** 1. Ask the user to re-enter the code. 2. If the OTP window has expired, start a new verification flow. otp_verification_invalid: >- This error occurs when the verification record exists but is not in a usable state for the requested operation. **Common causes:** - The verification is still pending (OTP not yet submitted successfully). - The verification has been revoked. - The verification channel does not match the expected field (`smsVerificationId` or `emailVerificationId`). **Steps to resolve:** 1. Complete a new verification flow and retry. otp_verification_not_found: >- The provided SMS or email verification ID does not correspond to any verification record. **Steps to resolve:** 1. Ensure you are passing the correct verification ID as `smsVerificationId` or `emailVerificationId`. 2. If the issue persists, complete a new verification flow. otp_verification_required: >- An SMS or email verification ID is required on order creation but none was provided. **Steps to resolve:** 1. Verify the user's phone number and email before creating an order. 2. Pass the returned verification IDs as `smsVerificationId` and `emailVerificationId` when creating orders. document_verification_failed: >- This error occurs when the user has not verified their identity for their coinbase.com account. **Steps to resolve:** 1. Verify your coinbase account identity with valid documents at https://www.coinbase.com/settings/account-levels. recipient_allowlist_violation: >- This error occurs when the user is not allowed to receive funds at this address, according to their coinbase account allowlist. **Steps to resolve:** 1. Either disable the allowlist or add the wallet address at https://www.coinbase.com/settings/allowlist 2. Wait approximately 2 days for updates to take effect. recipient_allowlist_pending: >- This error occurs when the user is not allowed to receive funds at this address, because changes to their coinbase account allowlist are pending. **Steps to resolve:** 1. Wait approximately 2 days for updates to take effect. refund_expired: >- Returned when a refund attempt is made after the payment session's refund deadline has passed. The payment session can no longer be refunded. travel_rules_recipient_violation: >- This error occurs when the user is not allowed to receive funds at this address, because it violates travel rules. **Steps to resolve:** 1. Ensure your desired transfer is not blocked by local travel regulations. mfa_already_enrolled: >- This error occurs when attempting to enroll in an MFA method that the user has already enrolled in. **Steps to resolve:** 1. Check if the user is already enrolled in the MFA method before initiating enrollment 2. To update or reset MFA, remove the existing enrollment first (if supported) 3. Use a different MFA method if multiple options are available mfa_invalid_code: >- This error occurs when the MFA code provided is incorrect or has already been used. **Steps to resolve:** 1. Verify the user entered the correct code from their authenticator app 2. Ensure the code is current (TOTP codes expire after 30 seconds) 3. Check that the device time is synchronized correctly 4. Ask the user to generate a new code and try again **Common causes:** - Typing errors in the 6-digit code - Using an expired TOTP code - Device clock drift on user's authenticator app - Attempting to reuse a previously submitted code mfa_flow_expired: >- This error occurs when the MFA enrollment or verification session has expired. **Steps to resolve:** 1. Restart the MFA enrollment or verification flow 2. Complete the flow within the allowed time window (typically 5 minutes) 3. Ensure the user doesn't leave the flow idle for extended periods **Note:** MFA sessions expire automatically for security purposes. mfa_required: >- This error occurs when attempting to perform a sensitive operation that requires MFA verification, but the user has not completed MFA verification. **Steps to resolve:** 1. Initiate the MFA verification flow using the `/mfa/verify/{mfaMethod}/init` endpoint 2. Prompt the user to enter their MFA code 3. Submit the verification using the `/mfa/verify/{mfaMethod}/submit` endpoint 4. Use the returned access token with MFA claim for the sensitive operation 5. Retry the original request with the new MFA-verified token **Operations requiring MFA:** - Transactions Sign/Send - Key export - Account management actions (when configured) mfa_not_enrolled: >- This error occurs when attempting to verify MFA for a user who has not enrolled in any MFA method. **Steps to resolve:** 1. Check if the user has enrolled in MFA before attempting verification 2. Guide the user through MFA enrollment first using the `/mfa/enroll/{mfaMethod}/init` endpoint 3. Complete enrollment before requiring MFA verification source_account_invalid: >- This error occurs when the source account specified in the transfer request is invalid or malformed. **Steps to resolve:** 1. Verify the account ID format is correct (e.g., `account_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`) 2. Ensure the account ID belongs to your CDP entity 3. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` **Common causes:** - Malformed account ID - Typo in the account ID target_account_invalid: >- This error occurs when the target account specified in the transfer request is invalid or malformed. **Steps to resolve:** 1. Verify the account ID format is correct (e.g., `account_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx`) 2. Ensure the account exists and can receive funds 3. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` **Common causes:** - Malformed account ID - Typo in the account ID source_account_not_found: >- This error occurs when the source account specified in the transfer does not exist. **Steps to resolve:** 1. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` target_account_not_found: >- This error occurs when the target account specified in the transfer does not exist. **Steps to resolve:** 1. Verify the account ID exists by calling `GET /v2/accounts/{accountId}` or `GET /v2/accounts` source_asset_not_supported: >- This error occurs when the asset specified in the transfer source is not supported for this transfer type. **Steps to resolve:** 1. Check the list of supported assets for the source account type 2. Verify the asset symbol is correctly specified (e.g., `usdc`, `usdt`) **Common causes:** - Unsupported asset for the transfer route - Incorrect asset symbol target_asset_not_supported: >- This error occurs when the asset specified in the transfer target is not supported for this transfer type. **Steps to resolve:** 1. Check the list of supported assets for the target 2. Verify the asset symbol is correctly specified (e.g., `usdc`, `usdt`) 3. Ensure the target can receive this asset type **Common causes:** - Asset not supported by the target - Unsupported conversion between source and target assets target_email_invalid: >- This error occurs when the email address specified as the transfer target is invalid. **Steps to resolve:** 1. Verify the email address format is valid (e.g., `user@example.com`) 2. Check for typos in the email address 3. Ensure the email domain is valid **Common causes:** - Invalid email format - Missing @ symbol or domain - Typo in the email address target_onchain_address_invalid: >- This error occurs when the onchain address specified as the transfer target is invalid for the specified network. **Steps to resolve:** 1. Ensure the network is supported for the transfer type 2. Verify the address format matches the target network 3. Ensure you haven't mixed up addresses from different networks **Common causes:** - Network not supported for the transfer type - Address format doesn't match network - Address from a different blockchain network transfer_amount_invalid: >- This error occurs when the transfer amount is invalid. **Steps to resolve:** 1. Ensure the amount is a positive number and greater than $1 USD equivalent amount 2. Verify the amount format is a valid decimal string (e.g., `"100.50"`) 3. Check the number of decimal places for the asset **Common causes:** - Zero or negative amount - Too many decimal places for the asset - Amount below minimum threshold ($1 USD equivalent amount) transfer_asset_not_supported: >- This error occurs when the asset specified for the transfer is not supported. **Steps to resolve:** 1. Check the list of supported assets for transfers 2. Verify the asset symbol is correctly specified 3. Ensure the asset is supported for the transfer route (source → target) **Common causes:** - Asset not supported for transfers - Incorrect asset symbol transfer_quote_expired: >- This error occurs when the transfer quote has expired. Quotes are valid for a limited time. **Steps to resolve:** 1. Create a new transfer to obtain a fresh quote 2. Execute the transfer promptly after creation **Common causes:** - Too much time elapsed between creating and executing the transfer insufficient_balance: >- This error occurs when the source account does not have enough funds to complete the transfer including fees. **Steps to resolve:** 1. Check the source account balance 2. Ensure the balance covers both the transfer amount and any fees 3. Consider using `amountType: "source"` to transfer the maximum available amount minus fees 4. Add funds to the source account if needed **Common causes:** - Transfer amount exceeds available balance - Not accounting for transfer fees - Pending transactions reducing available balance metadata_too_many_entries: >- This error occurs when the transfer metadata contains more entries than allowed. **Steps to resolve:** 1. Reduce the number of metadata entries (maximum 10 allowed) 2. Consolidate related data into fewer keys 3. Store additional data externally and reference it with a single metadata entry **Limits:** - Maximum entries: 10 metadata_key_too_long: >- This error occurs when a metadata key exceeds the maximum allowed length. **Steps to resolve:** 1. Shorten the metadata key to 40 characters or less 2. Use abbreviations or shorter naming conventions 3. Consider using a key-value structure where the value contains the longer identifier **Limits:** - Maximum key length: 40 characters metadata_value_too_long: >- This error occurs when a metadata value exceeds the maximum allowed length. **Steps to resolve:** 1. Shorten the metadata value to 500 characters or less 2. Store longer data externally and reference it with a shorter identifier 3. Consider compressing or encoding the data if appropriate **Limits:** - Maximum value length: 500 characters travel_rules_field_missing: >- This error occurs when required travel rule fields are missing from the transfer request. **Steps to resolve:** 1. Include the `travelRule` object in your transfer request 2. Supply the required missing fields prompted by the error message 3. Review the travel rule requirements for your jurisdiction Note: Required fields may vary by region. asset_mismatch: >- This error occurs when the assets specified in the transfer are incompatible or don't match expected values. **Steps to resolve:** 1. Ensure the `asset` field matches either the source or target asset 2. Verify that the source and target assets are compatible for conversion (if different) 3. Check that the asset symbols are correctly specified **Common causes:** - Transfer asset doesn't match source or target - Attempting an unsupported asset conversion - Typo in asset symbols order_quote_expired: >- This error occurs when attempting to execute an order whose quote has expired. **Steps to resolve:** 1. Create a new order with `execute: false` to get an updated quote. 2. Execute the new order before the quote expires (check the `expiresAt` field). 3. Alternatively, create a new order with `execute: true` to skip the quote step and execute immediately. order_already_filled: >- This error occurs when attempting to cancel or modify an order that has already been filled. **Steps to resolve:** 1. Check the current status of the order using `GET /v2/orders/{orderId}`. 2. A filled order cannot be canceled or re-executed. order_already_canceled: >- This error occurs when attempting to cancel or execute an order that has already been canceled. **Steps to resolve:** 1. Check the current status of the order using `GET /v2/orders/{orderId}`. 2. Create a new order if you still want to trade. account_not_ready: >- This error occurs when an operation is attempted on an account that is still being provisioned. **Steps to resolve:** 1. Wait a few moments and retry the request 2. If the error persists, the account may still be completing setup — retry with exponential backoff insufficient_liquidity: >- This error occurs when no swap route is available for the requested token pair or amount. **Steps to resolve:** 1. Try a smaller `fromAmount` — large orders may exceed available liquidity 2. Try a different token pair 3. Retry after a short delay; liquidity conditions change with market activity insufficient_allowance: >- This error occurs when the taker has not approved the Permit2 contract to spend the `fromToken` on their behalf. ERC-20 swaps require a Permit2 allowance. Native ETH swaps do not. **Steps to resolve:** 1. Submit an ERC-20 `approve` transaction on the `fromToken` contract, granting the Permit2 contract (`0x000000000022D473030F116dDEE9F6B43aC78BA3`) an allowance of at least `fromAmount` 2. Wait for the approval transaction to be confirmed on-chain 3. Retry the swap **Example:** ```typescript lines wrap // Approve Permit2 to spend fromToken await walletClient.writeContract({ address: fromToken, abi: erc20Abi, functionName: "approve", args: ["0x000000000022D473030F116dDEE9F6B43aC78BA3", fromAmount], }); ``` transaction_simulation_failed: >- This error occurs when the pre-broadcast simulation of the swap transaction predicted a revert. No transaction was submitted and no gas was spent. **Common causes:** - The on-chain price moved past the `slippageBps` tolerance between the price estimate and execution - Taker balance changed between the price estimate and execution **Steps to resolve:** 1. Retry immediately — prices change quickly and a new quote may succeed 2. Increase `slippageBps` if retries continue to fail (e.g. from 100 to 200) 3. For large swaps, consider splitting into smaller amounts to reduce price impact delegation_not_found: >- This error occurs when a delegated signing operation is attempted but no active delegation grant exists for the end user (or account). **Steps to resolve:** 1. Create a delegation grant using `createDelegationForEndUser` (user-scoped) or `createDelegationForEndUserAccount` (account-scoped) before calling the signing or sending operation 2. If you previously created a grant, it may have expired or been revoked — in those cases you would receive a `delegation_expired` or `delegation_revoked` error instead 3. For account-scoped grants, verify the address in the request matches the granted address (EVM addresses are compared case-insensitively; Solana addresses must match exactly) delegation_expired: >- This error occurs when the delegation grant used for signing has expired. Delegation grants have a limited lifetime set at creation. **Steps to resolve:** 1. Create a new delegation grant using `createDelegationForEndUser` or `createDelegationForEndUserAccount` 2. Retry the signing operation with the new grant active 3. Consider creating grants with a longer TTL if expiry is frequent delegation_revoked: >- This error occurs when the delegation grant has been explicitly revoked. **Steps to resolve:** 1. Create a new delegation grant using `createDelegationForEndUser` or `createDelegationForEndUserAccount` 2. Confirm with the end user before recreating, since revocation is typically intentional delegation_not_authorized: >- This error occurs when a delegation grant exists but does not authorize the requested operation. **Steps to resolve:** 1. For account-scoped grants, verify the signing address matches the address the grant was created for 2. Check that the operation is permitted for delegated signing on your project 3. Create a grant with the correct scope if needed delegation_not_enabled: >- This error occurs when delegated signing is attempted on a project that has not enabled the feature. **Steps to resolve:** 1. Enable delegated signing in your project configuration via the CDP Portal 2. Contact support if you believe delegated signing should already be enabled for your project network_mismatch: >- This error occurs when the requested operation specifies a network on which the target resource is not deployed or not available. **Steps to resolve:** 1. Use the network the resource was originally created or deployed on 2. Check the resource metadata to confirm the correct network **Common causes:** - Specifying `base` for a resource that only exists on `base-sepolia` (or vice versa) - Cross-network operation attempted on a resource scoped to a single network already_enabled: >- This error occurs when the requested operation cannot be performed because the capability is already in the desired state. **Steps to resolve:** 1. Check the current state of the resource before attempting the operation 2. No action is needed if the resource is already in the desired state **Common causes:** - Calling an enable endpoint on a resource that already has the feature enabled payment_session_already_canceled: >- This error occurs when an action is attempted on a payment session that has already been canceled. **Steps to resolve:** 1. Create a new payment session to proceed with the payment flow payment_session_already_authorized: >- This error occurs when attempting to authorize a payment session that has already been authorized. **Steps to resolve:** 1. Check the payment session status — it is already authorized 2. Proceed to capture, void, or other post-authorization actions as needed payment_session_action_pending: >- This error occurs when another action is already in progress for the payment session. **Steps to resolve:** 1. Wait for the current action to complete before retrying 2. Check the payment session status to confirm the current action result no_capturable_balance: >- This error occurs when there is no remaining balance available to capture on the payment session. **Steps to resolve:** 1. Verify the payment session status and previously captured amounts 2. Ensure the session was authorized and has uncaptured funds remaining no_voidable_balance: >- This error occurs when there is no held balance remaining to void on the payment session. **Steps to resolve:** 1. Verify the payment session has an authorized but uncaptured balance 2. Check whether the session has already been fully captured or voided no_refundable_balance: >- This error occurs when the payment session has no captured amount available to refund. **Steps to resolve:** 1. Verify the payment session has been previously captured 2. Check that the session has not already been fully refunded entity_not_configured_for_payment_acceptance: >- This error occurs when the entity is not configured to accept payments. **Steps to resolve:** 1. Contact support to enable payment acceptance for the entity daily_transaction_limit_exceeded: |- This error occurs when the daily transaction limit has been exceeded. **Steps to resolve:** 1. Wait until the next day when the daily limit resets 2. Contact support for questions about your limit daily_amount_limit_exceeded: >- This error occurs when the daily authorization amount limit has been exceeded. **Steps to resolve:** 1. Wait until the next day when the daily limit resets 2. Contact support for questions about your limit stale_attestation: >- The platform attestation (iOS App Attest assertion or Android Play Integrity token) was generated against a challenge that has since expired. The request was well-formed, but the challenge is no longer valid. **Steps to resolve:** 1. Call [Create Onramp Mobile Challenge](#operation/createOnrampMobileChallenge) to obtain a fresh challenge. 2. Re-run the platform attestation flow against the new challenge. 3. Submit the new attestation to [Create Onramp Mobile Session](#operation/createOnrampMobileSession) promptly — challenges are short-lived. **Common causes:** - Too much time elapsed between obtaining the challenge and submitting the attestation. moderation_rejected: |- The uploaded image failed content moderation and will not be served. **Steps to resolve:** 1. Upload a different image that complies with content policies. Url: type: string format: uri minLength: 11 maxLength: 2048 pattern: ^https?://.*$ description: A valid HTTP or HTTPS URL. example: https://example.com CapabilityName: type: string description: > The name of a capability. Capabilities represent granular functional permissions that determine what actions a customer can perform. Each capability must be explicitly requested before use. enum: - custodyCrypto - custodyFiat - custodyStablecoin - tradeCrypto - tradeStablecoin - transferCrypto - transferFiat - transferStablecoin example: custodyCrypto responses: PaymentMethodRequiredError: description: A payment method is required to complete this operation. content: application/json: schema: $ref: '#/components/schemas/Error' examples: payment_method_required: value: errorType: payment_method_required errorMessage: >- A valid payment method is required to complete this operation. Please add a payment method to your account at https://portal.cdp.coinbase.com. IdempotencyError: description: Idempotency key conflict. content: application/json: schema: $ref: '#/components/schemas/Error' examples: idempotency_error: value: errorType: idempotency_error errorMessage: >- Idempotency key '8e03978e-40d5-43e8-bc93-6894a57f9324' was already used with a different request payload. Please try again with a new idempotency key. InternalServerError: description: Internal server error. content: application/json: schema: $ref: '#/components/schemas/Error' examples: internal_server_error: value: errorType: internal_server_error errorMessage: An internal server error occurred. Please try again later. BadGatewayError: description: Bad gateway. content: application/json: schema: $ref: '#/components/schemas/Error' examples: bad_gateway: value: errorType: bad_gateway errorMessage: Bad gateway. Please try again later. ServiceUnavailableError: description: Service unavailable. content: application/json: schema: $ref: '#/components/schemas/Error' examples: service_unavailable: value: errorType: service_unavailable errorMessage: Service unavailable. Please try again later. securitySchemes: apiKeyAuth: type: http scheme: bearer bearerFormat: JWT description: >- A JWT signed using your CDP API Key Secret, encoded in base64. Refer to the [Generate Bearer Token](https://docs.cdp.coinbase.com/api-reference/v2/authentication#2-generate-bearer-token) section of our Authentication docs for information on how to generate your Bearer Token. ````