Rate Limits and Retries

WebSocket rate limiting protects persistent connections, authentication credentials, and device control channels.

Clients should treat rate limiting as a normal protection mechanism, not as a service failure.

Rate Limit Scope

Scope	Description
Create wsTicket	Limits frequent creation of one-time connection credentials
Establish WebSocket connection	Limits frequent connect, disconnect, and reconnect behavior
session.ping	Limits excessive application-layer heartbeat frequency
Request topics	Limits high-frequency requests within the same connection
Device control	Limits high-frequency control for the same device or the same relay

Recommended Frequency

Scenario	Recommended Value
session.ping	Once every 30 seconds
Reconnect after disconnect	Use exponential backoff with jitter
Create wsTicket	Create only before connecting; do not pre-create in bulk
Status query	Prefer event-driven updates instead of tight polling loops

Rate Limited

When a WebSocket request hits a rate limit, the service may return session.error:

{
  "type": "event",
  "topic": "session.error",
  "data": {
    "code": "RATE_LIMITED",
    "message": "Rate limit was exceeded."
  }
}

If POST /wlte/v1/ws/ticket is rate limited, the HTTP response uses 429 RATE_LIMITED.

Client Handling

• Reduce request frequency after receiving RATE_LIMITED
• Use exponential backoff when reconnecting; do not reconnect immediately in a loop
• Do not create wsTicket concurrently after a failure
• If device control is rate limited, wait until the current operation result stabilizes before sending the next operation

Relation to HTTP Rate Limits

POST /wlte/v1/ws/ticket is a REST endpoint and follows the REST API Rate Limits and Retries.

Requests and events after the WebSocket connection is established follow the rules on this page.