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
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