Errors
API Errors
The CDP API uses conventional HTTP response codes to indicate the success or failure of an API request. In general:
-
Codes in the
2xx
range indicate success -
Codes in the
4xx
range indicate an error that failed given the information provided (e.g., a required parameter was omitted) -
Codes in the
5xx
range indicate an error on CDP’s backend servers.5xx
errors are not a guarantee of failure; there’s always the chance that the operation may have succeeded in our back-end. Therefore, your application should treat the operation’s status as unknown.
Each error response includes:
errorType
: A machine-readable error codeerrorMessage
: A human-readable message providing more detailcorrelationId
: A unique identifier for the request that can help with debuggingerrorLink
: A link to detailed documentation about the specific error type
HTTP 400
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:
- Check all required fields and parameters are present
- Ensure request body (if applicable) follows the correct schema
- Verify all parameter formats match the API specification:
- Query parameters
- Path parameters
- Request headers
- 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
Example 1:
Example 2:
Example 3:
malformed_transaction
This error occurs when the transaction data provided is not properly formatted or is invalid.
Steps to resolve:
- Verify transaction encoding:
- EVM networks: Check RLP encoding is correct
- Solana: Validate base64 encoding
- Ensure all required transaction fields are present
- Validate transaction parameters are within acceptable ranges
- Check that the transaction type is supported on the target network (see our 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
Example error response:
invalid_signature
This error occurs when the signature provided for the given user operation is invalid.
Steps to resolve:
- Verify the signature was generated by the correct owner account
- Ensure the signature corresponds to the exact user operation hash
- Check that the signature format matches the expected format
- 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
Example error response:
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:
- Update project or accounts to remove references to the Policy in question.
- Retry your delete request.
Example error response:
HTTP 401
unauthorized
This error occurs when authentication fails.
Steps to resolve:
- Verify your CDP API credentials:
- Check that your API key is valid
- Check that your Wallet Secret is properly configured
- Validate JWT token:
- Not expired
- Properly signed
- Contains required claims
- Check request headers:
- Authorization header present
- X-Wallet-Auth header included when required
Security note: Never share your Wallet Secret or API keys.
Example 1:
Example 2:
HTTP 403
forbidden
This error occurs when you don’t have permission to access the resource.
Steps to resolve:
- Verify your permissions to access the resource
- Ensure that you are the owner of the requested resource
Example 1:
Example 2:
Example 3:
HTTP 404
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:
- Verify the resource ID/address/account exists
- Check your permissions to access the resource
- Ensure you’re using the correct network/environment
- 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
Example 1:
Example 2:
Example 3:
HTTP 409
already_exists
This error occurs when trying to create a resource that already exists.
Steps to resolve:
- Check if the resource exists before creation
- Use GET endpoints to verify resource state
- Use unique identifiers/names for resources
Example 1:
Example 2:
Example 3:
HTTP 422
idempotency_error
This error occurs when an idempotency key is reused with different parameters.
Steps to resolve:
- Generate a new UUID v4 for each unique request
- Only reuse idempotency keys for exact request duplicates
- Track used keys within your application
Example idempotency key implementation:
Example error response:
HTTP 429
rate_limit_exceeded
This error occurs when you’ve exceeded the API rate limits.
Steps to resolve:
- Implement exponential backoff
- Cache responses where possible
- Wait for rate limit window to reset
Best practices:
Example 1:
Example 2:
faucet_limit_exceeded
This error occurs when you’ve exceeded the faucet request limits.
Steps to resolve:
- Wait for the time window to reset
- Use funds more efficiently in your testing
For more information on faucet limits, please visit the EVM Faucet endpoint or the Solana Faucet endpoint.
Example error response:
HTTP 500
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:
- Retry your request after a short delay
- If persistent, contact CDP support with:
- Your correlation ID
- Timestamp of the error
- Request details
- Consider implementing retry logic with an exponential backoff
Note: These errors are automatically logged and monitored by CDP.
Example error response:
HTTP 502
bad_gateway
This error occurs when the CDP API is unable to connect to the backend service.
Steps to resolve:
- Retry your request after a short delay
- If persistent, contact CDP support with:
- The timestamp of the error
- Request details
- Consider implementing retry logic with an exponential backoff
Note: These errors are automatically logged and monitored by CDP.
Example error response:
HTTP 503
service_unavailable
This error occurs when the CDP API is temporarily unable to handle requests due to maintenance or high load.
Steps to resolve:
- Retry your request after a short delay
- If persistent, contact CDP support with:
- The timestamp of the error
- Request details
- Consider implementing retry logic with an exponential backoff
Note: These errors are automatically logged and monitored by CDP.
Example error response: