Skip to main content
Every Struct surface returns errors in a consistent shape. This page covers the wire format for REST and WebSocket. The TypeScript SDK exposes a typed hierarchy on top, documented in SDK Errors.

REST

Failed REST requests return the same envelope as successful ones, with success: false and a human-readable message. The HTTP status reflects the error class.

Status codes

Headers

On 429, the response includes Retry-After (seconds) when applicable. Honour it before retrying.

Retrying

Any 5xx, 429, network failure, or timeout is retryable. Use exponential backoff with jitter; never tight-loop. The TypeScript SDK does this automatically when retry is configured.

WebSocket

In-band errors

Invalid messages on either the rooms (/ws) or alerts (/ws/alerts) endpoint return a JSON error frame instead of closing the connection:
These cover protocol-level problems: unknown room IDs, malformed subscribe payloads, filter limits, and similar. The socket stays open; you can correct the message and retry.

Close codes

When the server closes the connection, it uses a standard WebSocket close code:

Reconnection

When the socket drops for any non-auth reason, reconnect with exponential backoff and resubscribe to every room you were previously in. Subscriptions are not persisted server-side; they live only for the lifetime of the connection. The TypeScript SDK handles reconnect and resubscribe automatically. See SDK WebSockets.

Webhooks

Webhook deliveries are retried automatically when your endpoint returns a non-2xx response, with exponential backoff. Endpoints that fail repeatedly are paused; see Webhooks for the full retry schedule.

SDK errors

The TypeScript SDK lifts these wire-level failures into a typed hierarchy:
See SDK Errors for the full hierarchy, retry behaviour, and example handlers.
Last modified on May 27, 2026