Error Handling
Every API response includes an X-Request-ID header so support can trace a failure without exposing internal details. Query API and direct route errors also include that value as requestId in their JSON body. Framework-generated RPC errors may expose it only in the header.
Error response
{
"success": false,
"error": "Human-readable error message",
"code": "ERROR_CODE",
"requestId": "req_abc123def456"
}Some validation failures also include details with the affected field and a suggested correction:
{
"success": false,
"error": "Unknown query type: summry. Did you mean 'summary'?",
"code": "VALIDATION_ERROR",
"requestId": "req_abc123def456",
"details": [
{
"field": "parameters[0]",
"message": "Unknown query type: summry",
"suggestion": "Did you mean 'summary'?"
}
]
}Query API codes
These are the stable codes returned by /v1/query and its subroutes:
Other API families can define additional codes. Treat code as the programmatic value and keep a fallback for unfamiliar codes.
Authentication response
Protected endpoints return a discovery hint in addition to the JSON body:
HTTP/1.1 401 Unauthorized
X-Request-ID: req_abc123def456
WWW-Authenticate: Bearer resource_metadata="https://api.databuddy.cc/.well-known/oauth-protected-resource"Rate-limit response
{
"success": false,
"error": "Rate limit exceeded",
"code": "RATE_LIMITED",
"requestId": "req_abc123def456",
"limit": 120,
"remaining": 0,
"reset": 1735732810000,
"retryAfter": 8
}reset is a Unix timestamp in milliseconds. retryAfter and the Retry-After header are seconds.
Partial query results
A valid multi-parameter query can contain a failure for one parameter while other parameters succeed:
{
"success": true,
"requestId": "req_abc123def456",
"data": [
{ "parameter": "summary", "success": true, "data": [] },
{
"parameter": "pages",
"success": false,
"error": "Query execution failed",
"data": []
}
]
}Check both the top-level success value and each result's success value.
Recovery checklist
How is this guide?