Error Response Format
All error responses follow a consistent structure:Error Codes
Authentication Errors (401)
| Code | Message | Solution |
|---|---|---|
authentication_error | Invalid or missing API key | Check your X-API-Key header |
authentication_error | Invalid API key format | Ensure key starts with triq_ |
Payment Errors (402)
| Code | Message | Solution |
|---|---|---|
insufficient_credits | Insufficient credits | Enable overages or upgrade plan |
Not Found Errors (404)
| Code | Message | Solution |
|---|---|---|
not_found | Resource not found | Verify the ID exists |
Validation Errors (422)
| Code | Message | Details |
|---|---|---|
validation_error | Validation failed | fieldErrors object with per-field errors |
Rate Limit Errors (429)
| Code | Message | Headers |
|---|---|---|
rate_limited | Rate limit exceeded | Retry-After, X-RateLimit-* |
Server Errors (500)
| Code | Message | Solution |
|---|---|---|
internal_error | An unexpected error occurred | Retry with exponential backoff |
Implementing Retry Logic
Exponential Backoff
Rate Limit Aware Retries
Error Handling Pattern
Here’s a complete error handling implementation:Logging and Monitoring
Request Logging
Error Tracking
Best Practices
Always include requestId in logs
Always include requestId in logs
The
meta.requestId helps with debugging and support requests.Implement circuit breakers for high-volume
Implement circuit breakers for high-volume
If errors persist, temporarily stop requests to prevent cascading failures.
Handle partial results separately
Handle partial results separately
Partial results (
partial: true) are successes with some failures handle them differently from full failures.Validate input before sending
Validate input before sending
Catch validation errors client-side when possible to reduce failed API calls.
Use structured error classes
Use structured error classes
Create error classes that make it easy to check error types and extract details.