Error Handling
Error codes and troubleshooting
Understanding error responses helps you build robust integrations and troubleshoot issues effectively.
Error Response Format
All errors follow a consistent structure:
Fields
| Field | Type | Description |
|---|---|---|
success | boolean | Always false for errors |
error.code | string | Machine-readable error code |
error.message | string | Human-readable description |
error.details | object | Additional context (optional) |
HTTP Status Codes
| Status | Meaning | Common Causes |
|---|---|---|
400 | Bad Request | Invalid input, missing fields |
401 | Unauthorized | Invalid/missing auth token |
403 | Forbidden | Valid auth but no permission |
404 | Not Found | Resource doesn't exist |
409 | Conflict | Duplicate resource |
422 | Unprocessable | Validation failed |
429 | Too Many Requests | Rate limit exceeded |
500 | Internal Error | Server-side bug |
503 | Service Unavailable | Maintenance/overload |
Error Codes
Authentication Errors
| Code | Status | Description |
|---|---|---|
UNAUTHORIZED | 401 | No auth token provided |
INVALID_TOKEN | 401 | Token is invalid or expired |
TOKEN_EXPIRED | 401 | Token has expired |
INVALID_API_KEY | 401 | API key is invalid |
SESSION_EXPIRED | 401 | Session has expired |
Example:
Validation Errors
| Code | Status | Description |
|---|---|---|
VALIDATION_ERROR | 400 | Input validation failed |
INVALID_FORMAT | 400 | Wrong format (email, UUID, etc.) |
MISSING_FIELD | 400 | Required field not provided |
INVALID_VALUE | 400 | Value out of allowed range |
Example:
Rate Limiting Errors
| Code | Status | Description |
|---|---|---|
RATE_LIMITED | 429 | Too many requests |
Headers included:
Example:
Resource Errors
| Code | Status | Description |
|---|---|---|
NOT_FOUND | 404 | Resource doesn't exist |
ALREADY_EXISTS | 409 | Duplicate resource |
RESOURCE_LOCKED | 423 | Resource is locked |
Payment Errors
| Code | Status | Description |
|---|---|---|
PAYMENT_FAILED | 400 | Payment was declined |
INVALID_SIGNATURE | 401 | Razorpay signature invalid |
ORDER_EXPIRED | 400 | Payment order expired |
ALREADY_PAID | 400 | Order already paid |
Server Errors
| Code | Status | Description |
|---|---|---|
INTERNAL_ERROR | 500 | Unexpected server error |
SERVICE_UNAVAILABLE | 503 | Service temporarily down |
DATABASE_ERROR | 500 | Database operation failed |
Handling Errors
JavaScript/TypeScript
Python
Best Practices
1. Always Check success
Don't assume a 200 status means success:
2. Handle Rate Limits
Implement exponential backoff:
3. Log Error Details
Include context for debugging:
4. Show User-Friendly Messages
Don't show raw error messages to users:
Debugging
Check the Error Code
The code field is the most reliable way to handle errors programmatically.
Read the Details
The details object often contains helpful context:
- Validation errors: Which fields failed
- Rate limits: When you can retry
- Conflicts: What resource already exists
Check Response Headers
Headers often contain useful info:
X-Request-Id: For support ticketsX-RateLimit-*: Rate limit status
Getting Help
If you encounter unexpected errors:
- Check the error code and message
- Review the Troubleshooting guide
- Search Discord for similar issues
- Contact Support with:
- Error code and message
- Request ID (from headers)
- Steps to reproduce
Next Steps
- API Endpoints — Full API reference
- Rate Limits — Understand limits
- Troubleshooting — Common issues