Skip to main content

Response format

Success responses

Successful requests return a JSON object with the following shape:
{
  "success": true,
  "message": "wallets retrieved successfully",
  "data": { ... },
  "meta": { ... }
}
FieldTypeDescription
successbooleanAlways true for successful requests.
messagestringA human-readable description of the result.
dataobject or arrayThe response payload. May be an object, an array, or empty {}.
metaobjectMetadata such as pagination info. Empty {} when not applicable.

Error responses

Failed requests return a JSON object with the following shape:
{
  "success": false,
  "message": "TRX_TEST for your-wallet-label already exists in your wallets",
  "meta": {},
  "errors": [],
  "data": {}
}
FieldTypeDescription
successbooleanAlways false for failed requests.
messagestringA human-readable description of what went wrong.
errorsarrayAdditional error details when available.
metaobjectEmpty for error responses.
dataobjectEmpty for error responses.
Not all error responses include every field. See the exceptions for 429 and 500 below.

Common error scenarios

400 - Bad request

Returned when the request is invalid or violates a business rule. Duplicate wallet label:
{
  "success": false,
  "message": "TRX_TEST for your-wallet-label already exists in your wallets",
  "meta": {},
  "errors": [],
  "data": {}
}
This occurs when you attempt to generate a wallet address with a label that already exists for the same asset.

401 - Unauthorized

Returned when authentication credentials are missing or invalid. Ensure you are sending the correct x-app-id and x-app-secret headers, and that the X-Breet-Env header is set to either development or production. See the quickstart for how to obtain and configure your credentials.

403 - Forbidden

Returned when your account does not have permission to perform the requested action.
{
  "success": false,
  "message": "access is forbidden",
  "meta": {},
  "errors": [],
  "data": {}
}

404 - Not found

Returned when the requested resource does not exist. Wallet not found:
{
  "success": false,
  "message": "wallet not found",
  "meta": {},
  "errors": [],
  "data": {}
}
Transaction not found:
{
  "success": false,
  "message": "transaction not found",
  "meta": {},
  "errors": [],
  "data": {}
}

409 - Conflict

Returned when the request conflicts with the current state of a resource, such as attempting to create a resource that already exists.

422 - Unprocessable entity

Returned when the request is well-formed but cannot be processed due to a validation or business logic constraint.
{
  "success": false,
  "message": "wallet does not have a bank",
  "meta": {},
  "errors": [],
  "data": {}
}
This commonly occurs when enabling auto-settlement on a wallet that doesn’t have a linked bank account.

429 - Too many requests

Returned when you exceed the rate limit. Back off and retry after the time indicated in the Retry-After response header (value in seconds).
The 429 response body does not follow the standard error shape. It only returns a message field:
{
  "message": "Too many requests. Please try again later."
}
Your error handling should account for this exception.

500 - Internal server error

Returned when an unexpected error occurs on the server. The response body includes success, message, meta, and errors, but does not include a data field:
{
  "success": false,
  "message": "something went wrong!",
  "meta": {},
  "errors": []
}
For 500 errors, implement retry logic with exponential backoff.

Best practices

  • Always check the success field before processing the response.
  • Use the message field for logging and debugging. Do not rely on exact message text for control flow, as messages may change.
  • Handle 4xx errors gracefully in your application with appropriate user feedback.
  • For 429 errors, read the Retry-After header to determine how long to wait before retrying.
  • For 5xx errors, implement retry logic with exponential backoff.