Diddo’s API follows standard HTTP conventions and returns structured error responses to help you debug and recover from failed requests.
This section covers:
- Error response format
- Recoverable errors
- Non-recoverable errors
- HTTP status codes
- Testing error responses
🧾 Error Response Format
All error responses follow a consistent structure:
json♻️ Recoverable Errors
| Status Code | Meaning | Retry Guidance |
|---|---|---|
429 | Rate limited | Use exponential backoff |
500 | Server issue | Retry after short delay |
503 | Service unavailable | Retry later |
❌ Non-Recoverable Errors
| Status Code | Meaning | Resolution |
|---|---|---|
400 | Malformed input or invalid parameters | Check and fix input |
401 | Missing or invalid API key | Provide valid credentials |
403 | Authenticated but not authorized | Verify access permissions |
🔁 HTTP Status Codes
| Status Code | Meaning |
|---|---|
200 | OK — Request succeeded |
201 | Created — Resource successfully created |
400 | Bad Request — Invalid input or malformed request |
401 | Unauthorized — Missing or invalid API Key |
403 | Forbidden — Authenticated, but lacking permissions |
404 | Not Found — Resource does not exist |
409 | Conflict — Resource already exists or in conflicting state |
422 | Unprocessable Entity — Validation failed on input fields |
429 | Too Many Requests — Rate limit exceeded |
500 | Internal Server Error — Something went wrong on our end |
🧪 Test Error Responses 🔗
You can simulate error responses in sandbox mode by using test tokens or deliberately invalid inputs (e.g. missing fields, wrong IDs).