Overview
This section describes how to handle errors while integrating with the CryptoMate API. Following these conventions will speed up debugging and make support interactions much faster.
Request tracing
Every failing request includes a trace_id in the error response body that uniquely identifies the call. Include it in any support request or troubleshooting conversation — it gives us everything we need to find the failing request and figure out what went wrong.
Failed requests return a JSON object with the following fields:
code — identifies the specific error type.message — human-readable description of the error.trace_id (optional) — unique identifier for the failing request, useful for troubleshooting.
Example
{
"code": "NOT_FOUND",
"message": "Resource not found",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}
HTTP status codes
| Code | Meaning |
|---|
200 / 201 | Successful request |
400 | Invalid request — verify the body of POST/PUT/PATCH calls or the parameters of GET/DELETE calls |
401 | The API Key is not authorized for this operation — check its configuration |
404 | The requested resource does not exist — verify the identifier |
412 | Internal validation failure — inspect the request body |
429 | Rate limit exceeded — back off and retry; see Rate Limiting |
500 | Server-side issue — retry later and contact support if it persists |
trace_id in the Portal
When an action triggered from the Portal fails, the error dialog shows the trace_id alongside the error message so it can be copied and shared for troubleshooting.
Always log the trace_id alongside your own request identifiers. It turns a “the API is broken” ticket into a conversation we can resolve in minutes.
