Skip to main content

HTTP Status Codes

The API returns standard HTTP status codes:
  • 2xx - Success
  • 4xx - Client errors (invalid request, authentication, etc.)
  • 5xx - Server errors

Error Response Format

All error responses follow a consistent structure:
error
object
Error information container
error.code
string
Machine-readable error code for programmatic handling
error.message
string
Human-readable error description
error.details
object
Additional context-specific error information
error.request_id
string
Unique identifier for this request, used for support and debugging
error.timestamp
string
ISO 8601 timestamp when the error occurred

Error Code Categories

StatusError CodeDescriptionRetryable
400INVALID_REQUESTMalformed request syntaxNo
401UNAUTHORIZEDInvalid or missing API keyNo
403FORBIDDENInsufficient permissionsNo
404NOT_FOUNDResource does not existNo
409CONFLICTResource state conflictNo
422VALIDATION_ERRORRequest validation failedNo
429RATE_LIMIT_EXCEEDEDToo many requestsYes
500INTERNAL_ERRORServer errorYes
502BAD_GATEWAYUpstream service errorYes
503SERVICE_UNAVAILABLETemporary service outageYes
504TIMEOUTRequest timeoutYes

Retry Strategy

const MAX_RETRIES = 3;
const BASE_DELAY = 1000; // 1 second

async function apiRequestWithRetry(request, attempt = 1) {
  try {
    return await makeRequest(request);
  } catch (error) {
    if (attempt >= MAX_RETRIES || !isRetryable(error)) {
      throw error;
    }

    const delay = BASE_DELAY * Math.pow(2, attempt - 1);
    await sleep(delay);
    return apiRequestWithRetry(request, attempt + 1);
  }
}

Retry Guidelines

  • Exponential Backoff: Start with 1s, double each retry (1s, 2s, 4s)
  • Jitter: Add randomization to prevent thundering herd
  • Maximum Retries: Limit to 3 attempts for 5xx errors
  • Non-Retryable: Do not retry 4xx errors (except 429)

Circuit Breaker Pattern

For high-volume integrations, implement circuit breaker pattern:
  • Failure Threshold: 5 consecutive failures
  • Timeout Period: 30 seconds
  • Recovery: Gradual recovery with limited requests
400 errors are typically developer errors that can be fixed by updating your request. 422 errors contain user-friendly messages that can be shown to end users. Always log the request_id for support inquiries.

Request Tracking

Each error response includes a unique request_id for debugging:
  • Include this ID when contacting support
  • Request IDs are retained for 30 days
  • Correlate client-side errors with server-side logs