Rate Limits and Retries

WebSocket connections, messages, and device operations may be rate limited. Clients should treat RATE_LIMITED as a recoverable request result, not as a connection failure.

Recommendations

• Send session.ping about every 30 seconds
• Reconnect with exponential backoff and random jitter
• Create a wsTicket only immediately before connecting
• Prefer events for state updates instead of repeatedly requesting real-time state
• Control multiple relays with one relays array

When a Request Is Limited

A rate-limited WebSocket request receives a reply correlated with the original request:

{
  "type": "reply",
  "requestId": "req_001",
  "code": "RATE_LIMITED",
  "message": "Too many requests",
  "data": {
    "retryAfterSeconds": 1,
    "rateLimitScope": "device.dispatch",
    "limit": 6,
    "windowSeconds": 10
  }
}

Retry after the delay in data.retryAfterSeconds. Do not try to bypass the limit by reconnecting repeatedly, switching to REST, or sending the same operation concurrently.

data.rateLimitScope identifies the rate-limit bucket, not an API Client permission. The legacy data.scope field remains temporarily for compatibility and should not be used by new clients.

DEVICE_BUSY means that another operation is currently communicating with the device. Wait for it to finish before retrying; this is not a connection error and should not be bypassed by opening another connection.

If POST /wlte/v1/ws/ticket returns HTTP 429, follow the REST API Rate Limits and Retries guidance.