---
title: "Rate limits"
description: "How Enterprise API v2 rate limits work, how they're scoped, and how to stay within them."
icon: "gauge-high"
---

> **For AI agents:** the complete documentation index is at [llms.txt](/llms.txt). Append `.md` to any page URL for its markdown version.

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.

| Tier | Applies to | Sustained rate | Burst |
|------|------------|----------------|-------|
| **Standard** | Management & ingestion: things, sites, fleets, thing-type & metric definitions, templates, integrations, and data ingestion (`/v2/thing/{id}/data*`, template apply) | 60 requests / minute | up to 100 |
| **Data read** | High-volume timeseries queries (`/v2/.../timeseries`, `/summary`, recent data) | 600 requests / minute | up to 1,000 |

<Note>These are the default limits. Your plan may have higher limits — see [Requesting higher limits](#requesting-higher-limits).</Note>

## 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
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).