Skip to main content
The WireSocket dataplane is a globally distributed set of WebSocket nodes. This page covers how to connect your editor, handle regions, and manage token renewal and reconnection.

Regions

WireSocket has two region concepts you need to understand: License Region — Set during app creation. Defines where your app’s license and plan data is stored. This is the dbCode claim in your JWT. These regions always have an aws- prefix. WebSocket Regions — The standard cloud regions where your editors connect for real-time sync. Each region maps to a specific Sync Cluster and has its own URL:
Example: eu-central-1 (Region: Europe Central, Cluster: 1). Currently available WebSocket regions and their URLs are listed in your dashboard.
License Region (dbCode) and WebSocket region (regionCode) are independent. Your license can be stored in EU while your editors connect to a US node.

Document Discovery

WireSocket supports two strategies for connecting to the correct regional node for your document: Both are fully supported. Use Discovery if first-connect latency matters. Use connect-and-catch if you want to avoid the extra HTTP round trip.

Discovery First

Response:
A 401 or 400 response means a configuration problem — invalid token or missing documentName. Do not retry automatically. Surface the error to the developer.

Connect and Catch

If you prefer to skip the HTTP round trip entirely, connect directly to any regional node. If the region is wrong, WireSocket closes the connection with a 4009 code and the correct URL in the close reason — your client catches this and reconnects transparently.

Document ID Format

Pass any string as your document ID. WireSocket handles isolation internally by prefixing it with tenantId::appId:: before it reaches the storage layer. Recommendations:
  • Keep document IDs under 255 characters
  • Use URL-safe characters — alphanumeric, hyphens, underscores

Connecting Your Editor

TipTap


Passing the Token

Three methods are supported. All work in all regions. The subprotocol method is preferred — it keeps the token out of server access logs and browser history.

Token Expiry & Reconnection

JWT validation happens at handshake only. Once connected, an expiring token does not drop an active session. When your token is close to expiry, reconnect with a fresh token:
Reconnecting re-validates the JWT against the JWKS endpoint and re-reads plan limits from the token claims (dbCode). This is the correct way to pick up plan changes or credential rotations.
Last modified on March 3, 2026