Error response format
Every error response follows this structure:| Field | Type | Description |
|---|---|---|
code | string | Machine-readable error code (see table below) |
message | string | Human-readable description |
details | array | Field-level validation errors (only for VALIDATION_ERROR) |
request_id | string | Unique request ID for debugging — include this when contacting support |
HTTP status codes
| Status | Code | Description |
|---|---|---|
400 | VALIDATION_ERROR | Request body failed validation |
400 | BAD_REQUEST | Malformed request (invalid JSON, missing headers, etc.) |
401 | UNAUTHORIZED | Missing, invalid, inactive, or expired API key |
403 | FORBIDDEN | API key lacks required permission |
404 | NOT_FOUND | Resource does not exist or is not accessible |
409 | CONFLICT | Resource already exists (e.g., duplicate tool name) |
429 | RATE_LIMITED | Too many requests — see Rate Limiting |
500 | INTERNAL_ERROR | Server error — retry or contact support |
Validation errors
When a request fails validation, thedetails array contains field-level errors:
Handling errors in code
JavaScript / TypeScript
Python
Debugging tips
- Check the
request_id— Include it when contacting support for faster resolution - Read
detailsfor validation errors — They tell you exactly which fields failed and why - Check rate limit headers — If you’re getting
429s, inspectX-RateLimit-Remainingbefore retrying - Verify permissions —
403errors always include the missing permission in the message