Skip to main content
LeoKit provides comprehensive error tracking through trace IDs. Every API error includes a trace_id that you can use to retrieve detailed debugging information, including the full request context, error details, and timestamps.

How Trace IDs Work

When an API request fails, the error response includes a trace_id:
You can use this trace_id to retrieve full error details from the tracking endpoint.

Retrieving Error Details

Endpoint

Example Request

Response

Response Fields

Common Use Cases

1. Debugging Failed Deposits

2. Error Pattern Analysis

Track error frequencies to identify systemic issues:

3. Customer Support Integration

Display error details to support agents:

4. Automated Monitoring

Set up alerts for critical errors:

Error Categories

Errors are grouped into categories for easier debugging:

Validation Errors (HTTP 400)

Client-side issues like invalid parameters or malformed requests. Common Codes:
  • BAD_REQUEST - Malformed JSON or invalid types
  • WRONG_PROTOCOL - Unsupported protocol selected
  • INVALID_TOLERANCE_BPS - Slippage tolerance out of range
Debugging:

Balance & Amount Errors (HTTP 400)

Insufficient funds or amounts outside valid ranges. Common Codes:
  • INSUFFICIENT_BALANCE - Not enough tokens/gas
  • NOT_ENOUGH_GAS - Can’t pay transaction fees
  • UNDER_DUST_LIMIT - Output amount too small
Debugging:

Quote & Transaction Errors (HTTP 400/404)

Issues with quotes or transaction generation. Common Codes:
  • QUOTE_EXPIRED - Quote older than 15 minutes
  • QUOTE_NOT_FOUND - Invalid quote_id
  • NO_ROUTES_AVAILABLE - No protocols support this swap
Debugging:

Server & Protocol Errors (HTTP 500/503)

Backend or protocol integration issues. Common Codes:
  • INTERNAL_SERVER_ERROR - Unexpected server error
  • PROTOCOL_TIMEOUT - Protocol didn’t respond in time
  • BLOCKCHAIN_SYNC_ERROR - Node syncing issue
Debugging:

Retention Policy

Error logs are retained for 30 days. Download critical traces within this window.
After 30 days, the trace endpoint will return:

Best Practices

Always save trace_id - Store it in your database alongside transaction records for later debugging.
Show trace_id to users - Include it in error messages so users can reference it in support tickets.
Implement retry logic - For transient errors like PROTOCOL_TIMEOUT, automatically retry with exponential backoff.
Log error patterns - Track which errors occur most frequently to improve your integration.
Use context fields - The context object contains actionable debugging information specific to each error type.

Error Response Handling

Build a robust error handler that uses trace IDs:

Next Steps

Error Reference

Complete list of all 46 error codes

Complete Swap Flow

Learn the complete swap workflow