When a call fails, the service returns the following error structure, where request_id matches the x-request-id response header:
{
"type": "error",
"error": {
"code": "405",
"message": "Method not allowed"
},
"request_id": "82a2ff07-d30f-9905-b9d3-fa2d1c122e01"
}
| code | HTTP status | Description |
|---|
| 405 | 405 | Method not allowed |
| 400 | 400 | Parameter validation failed; message gives the reason |
| InvalidApiKey | 401 | API Key missing or invalid (gateway layer) |
| Endpoint.AccessDenied | 403 | Workspace does not exist or is not accessible (gateway layer) |
| BadRequest.IllegalEndpoint | 400 | Workspace route is invalid (gateway layer) |
Authentication and workspace-routing errors are returned directly by the gateway in a flat {"request_id", "code", "message"} structure; business errors are returned by the service, with the error code in error.code.
| HTTP status | Description |
|---|
| 400 | Missing parameter, malformed format, or value out of range |
| 401 | Invalid API Key |
| 403 | No access to the workspace |
| 404 | Resource not found |
| 405 | Method not allowed |
| 500 | Internal service error |
When troubleshooting, use request_id to locate the specific request. After resolving errors, continue with the endpoint documentation in the Overview. 
