Error Handling
Ticksupply uses consistent error responses across all endpoints. This guide covers error formats, common error codes, and best practices for handling errors.Error response format
All errors follow this structure:| Field | Description |
|---|---|
code | Machine-readable error code for programmatic handling |
message | Human-readable description of the error |
details | Optional additional error context (when available) |
X-Request-Id header (e.g., req_7f8e9d0c1b2a3456). Include this value when contacting support.
Error codes reference
| Code | HTTP Status | Description |
|---|---|---|
invalid_argument | 400 | Request validation failed |
unauthenticated | 401 | Missing or invalid API key |
permission_denied | 403 | Valid key, but lacks permission |
not_found | 404 | Resource doesn’t exist |
already_exists | 409 | Resource already exists or idempotency conflict |
rate_limited | 429 | Too many requests |
internal | 500 | Server error (contact support if persistent) |
unavailable | 503 | Service temporarily unavailable |
Handling errors by type
Authentication errors (401)
- Missing
X-Api-Keyheader - Invalid or expired API key
- Typo in the API key
Validation errors (400)
- Missing required parameters
- Invalid parameter types or values
- Malformed request body
Not found errors (404)
- Resource was deleted
- Incorrect resource ID
- Resource belongs to a different account
Rate limit errors (429)
Retry-After: Seconds to wait before retrying
Server errors (500, 503)
Complete error handling example
Request tracing
Every response includes anX-Request-Id header:
Best practices
Always check response status codes
Always check response status codes
Don’t assume requests succeed. Check status codes and handle errors appropriately.
Implement exponential backoff
Implement exponential backoff
For retryable errors (429, 5xx), use exponential backoff to avoid overwhelming the API.
Log request IDs
Log request IDs
Store
X-Request-Id values in your logs for debugging and support requests.Use idempotency keys for retries
Use idempotency keys for retries
When retrying mutating operations, use the same idempotency key to avoid duplicates.
Don't retry client errors
Don't retry client errors
4xx errors (except 429) indicate issues with your request. Fix the request rather than retrying.
Getting help
When contacting support about errors:- Include the
X-Request-Idheader value from the response - Describe what you were trying to do
- Include the request method and endpoint
- Note the approximate time of the error