Skip to main content

​
Error Event Format

Errors arrive as SSE events: 
event: error
data: {"error":"Invalid configuration","code":"VALIDATION_ERROR","retryable":false}

interface ErrorEvent {
  error: string;
  code?: string;
  retryable?: boolean;
}

​
Error Codes

CodeHTTP StatusRetryableDescription
VALIDATION_ERROR400NoInvalid request body or parameters
AUTHENTICATION_ERROR401NoInvalid or missing API key
RATE_LIMIT_ERROR429YesToo many requests
PROCESSING_ERROR500YesInternal processing failure
TIMEOUT_ERROR504YesRequest took too long

​
Common Errors

​
VALIDATION_ERROR

Missing required fields (config, userPrompt), invalid GraphConfig structure, or malformed JSON. Resolution: Check the request body against the schema.

​
AUTHENTICATION_ERROR

Missing Authorization header, malformed header (missing Bearer prefix), or invalid API key. Resolution: Verify the API key and header format.

​
RATE_LIMIT_ERROR

Too many requests in a short period. Resolution: Implement exponential backoff and retry.

​
PROCESSING_ERROR / TIMEOUT_ERROR

Internal failure or request took too long. Resolution: Retry with exponential backoff. If persistent, contact support.

​
HTTP Status Codes

Errors may also arrive as HTTP status codes before streaming begins:
StatusDescription
400Bad Request — Invalid JSON or missing fields
401Unauthorized — Invalid or missing API key
429Too Many Requests — Rate limit exceeded
500Internal Server Error — Processing failure
504Gateway Timeout — Upstream timeout

​
Retry Strategy

For retryable errors, use exponential backoff: 
delay = base_delay * (backoff ^ attempt)
Recommended defaults:
  • base_delay: 1000ms
  • backoff: 2
  • max_attempts: 3
AttemptDelay
10ms (immediate)
21000ms
32000ms
Best practices:
  • Only retry if retryable: true
  • Set a maximum retry count
  • Treat network failures as retryable
  • The API is stateless, so retries are safe