Rate limits and payload limits
Which limit applies to a device, a gateway, a stream and a signed-in user, and what to do when you hit one.
Logable enforces a rate limit and a payload limit on every ingest call. Neither one is a suggestion: both are checked before the reading is stored.
Four limits#
Logable applies four limits, in two services: three in ingest, one in the API. Each is counted differently, and hitting one does not affect the others.
| Service | Limit | Description |
|---|---|---|
| Ingest over HTTP | 10 per second | Per device or per stream. Over the limit, the request gets a 429 with retryAfter. |
| Ingest over MQTT | 10 per second | Per device or per stream. Over the limit, the message is dropped without a reply. The device log shows the drop. |
| Ingest, per organization | 200 per second | Across every device and stream the organization owns, on both transports. A gateway that fronts many devices counts against its organization, not against an address. |
| Logable API | 100 per minute | Per signed-in user. The web and mobile apps stay under it. Devices never touch it. |
A gateway publishing for many devices is still limited per device, on that device's own id, not on the gateway as a whole. The per-organization row is the one exception: it counts every device and stream the organization owns together, on both transports, at 200 per second. A gateway fronting many devices shares its organization's ceiling instead of getting one of its own.
What a device should do#
Send at the equipment's real reporting cadence. There is no reason to publish faster than the equipment produces new values, and doing so is the most common way a device reaches these limits.
Over HTTP, a request past the limit gets a 429 with a retryAfter field in the body, in seconds. Wait that long before trying again.
Over MQTT, an excess message is dropped with no reply. There is no failure code to catch on the wire. Watch the device's Device log, which shows the rejection with the reason, or its dashboard status, to notice the gap.
Payload limits#
These bound the whole payload, whether a key is a field the device type declares or a custom one.
| Limit | Value | Description |
|---|---|---|
| data keys | 100 | Maximum number of keys in the data object. |
| key length | 100 | Maximum characters in any data or metadata key. |
| string value length | 1000 | Maximum characters in a string value. |
| metadata keys | 50 | Maximum number of keys in the metadata object. |
| metadata size | 16 KB | Maximum serialised size of the metadata object. |
| nesting depth | 32 | Maximum object nesting Logable walks before it rejects the payload. |
Custom keys#
A tighter set of limits applies to the custom subset only, the keys a payload carries beyond what the device type declares. See Send a field the device type does not define.
| Limit | Value | Description |
|---|---|---|
| custom keys | 20 | Maximum number of custom (unregistered) keys in one payload. |
| key length | 64 | Maximum characters in a custom key. |
| string value length | 256 | Maximum characters in a custom key's string value. |
Timestamps#
A payload's timestamp is optional. When you send one, it has to sit within one hour of Logable's own clock, in either direction. Further than that, the request fails with 400.
Omit timestamp and Logable uses the time it received the reading instead.