Rate limiting

IP-Based rate limiting

This solution restrict the number of requests that client can make per time period based on IP address. For example, if too many requests are made from the same IP address within a short time (say, more than 100 per minute), further requests will be rejected.

The limit is 4000 RPM per IP address.

When a request is denied, the service responds with HTTP 429 Too Many Requests, but the response DOES NOT include a Retry-After header.

Auth-Based rate limiting

This solution uses authentication data to limit the number of HTTP requests per time period and per scope (for example, 10 requests per minute (RPM) per user).

There are four scopes depending on who made the request:

And one special scope:

The per-project limit is special because, unlike the others, it applies regardless of who made the request. For example, if 10 users are each sending 600 RPM, the 11th user may still have a personal (per-user) quota left, but the shared (per-project) quota will already be exhausted. So 11 users cannot all send 600 RPM simultaneously - some requests will be rejected.

When a request is denied, the service responds with HTTP 429 Too Many Requests, and the response includes a Retry-After header.

Note that messages published by devices count as device requests. This means that if a device sends 200 messages per minute, it can make only an additional 400 requests to any API within the same time period.

Note that device connection events also count toward the per-device quota. If a device opens a new connection each time it sends a message, it can only send around 300 messages per minute (300 connections + 300 messages). Technically, the actual number could be even lower because each device is limited to 5 simultaneous connections.

Auth-Based connection limiting

This solution uses authentication data to limit the number of parallel connections each device can have (for example, each device cannot have more than 5 connections at the same time).

The limit per device is 5 parallel connections.

Ths limit is applied to Mqtt connections and /:deviceId/command endpoint with a common limit.

This means that if a user already has 1 active WebSocket connection to /:deviceId/command endpoint, the same device can open only 4 additional connections to Mqtt at the same time.