Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cryptomate.me/llms.txt

Use this file to discover all available pages before exploring further.

​
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.

​
Error response format

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

CodeMeaning
200 / 201Successful request
400Invalid request — verify the body of POST/PUT/PATCH calls or the parameters of GET/DELETE calls
401The API Key is not authorized for this operation — check its configuration
404The requested resource does not exist — verify the identifier
412Internal validation failure — inspect the request body
429Rate limit exceeded — back off and retry; see Rate Limiting
500Server-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.