Rate limits

To keep the API fast and reliable for everyone, requests are rate limited. This page explains how the limits work, how they're scoped, what happens when you exceed them, and how to build integrations that stay within them.

How limits are scoped

Rate limits apply per organization — not per API key.

All API keys belonging to your organization draw from the same shared limit. Creating additional API keys does not increase your capacity; it's a single budget for your whole organization, enforced consistently across every request regardless of which key you use.

Limit tiers

Endpoints fall into one of two tiers, each with its own independent budget. Heavy use of one tier never consumes the other.

How the limits work (burst + sustained)

Each tier behaves like a refilling bucket of requests:

• Your bucket holds up to the burst amount (e.g. 100 for Standard).
• Every successful request spends one.
• The bucket refills continuously at the sustained rate (e.g. 60/minute = 1 per second).

This means you can send a short burst up to the bucket size, after which you're paced at the sustained refill rate. If you stay at or below the sustained rate, you'll rarely be limited; brief spikes above it are absorbed by the burst allowance.

When you exceed a limit

The API responds with HTTP 429 Too Many Requests, a Retry-After header (seconds to wait), and an application/problem+json body:

HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/problem+json

{
  "status": 429,
  "title": "Too Many Requests",
  "detail": "API rate limit exceeded. Retry after the period indicated by the Retry-After header."
}

Always honor the Retry-After header — it tells you exactly how long to wait before the next request will be accepted.

Handling rate limits

Best practices for a resilient integration:

1. Respect Retry-After. On a 429, wait the indicated number of seconds before retrying.
2. Use exponential backoff with jitter for retries, so bursts of traffic don't resynchronize and re-collide.
3. Batch your writes. Data ingestion is on the Standard tier, so prefer many readings per request instead of many requests:
   • Send multiple data frames in one call to POST /v2/thing/{thingId}/data.
   • Use the compact columnar endpoint POST /v2/thing/{thingId}/data/columnar for high-volume telemetry.
4. Trim reads. Use the fields projection and pagination on list/timeseries endpoints to get what you need in fewer, smaller calls.
5. Spread load over time rather than issuing large synchronized bursts.
6. Don't create extra API keys to get more throughput — limits are per organization, so it won't help.

Requesting higher limits

If your workload needs more than the default limits, higher per-organization limits are available. Contact your account team or support with your organization, the tier(s) you need raised, and your expected request volume.

FAQ

Do more API keys give me a higher limit?

No. Limits are per organization and shared across all your keys.

Are the Standard and Data-read limits separate?

Yes — they're independent budgets. Exhausting one doesn't affect the other.

Which limit applies to data ingestion?

The Standard tier (request-rate based). Because each request can carry many readings, batch your data (multiple frames, or the columnar endpoint) rather than sending one request per reading.

How do I know how long to wait after a 429?

Use the Retry-After response header (in seconds).