Rate limits

The Public API enforces plan-based rate limits per organization. All requests made with API keys belonging to the same organization share one limit and one hourly usage bucket — the limit is not per API key.

Window

The rate limit window is one hour, and buckets align to the top of the hour in UTC. Your usage resets at 00:00, 01:00, 02:00 UTC, and so on — not on a rolling window that starts with your first request.

Limits by plan

The limit is determined by your organization's plan:

Plan	Requests per hour
beta (default)	2,000
starter	10,000
growth	50,000
scale	200,000

Every new organization starts on the beta plan, which is free during beta. Limits can also be adjusted per organization through an override applied by Floatless — if you need a temporary raise for a migration or backfill, contact support.

You can read the current limits at runtime from the rate_limits object in the GET /meta response.

Response headers

Every Public API response includes headers describing your current rate limit state:

X-RateLimit-Limit: 2000
X-RateLimit-Remaining: 1937

Header	Meaning
X-RateLimit-Limit	Your organization's total requests per hour
X-RateLimit-Remaining	Requests left in the current hour bucket

Read X-RateLimit-Remaining proactively (for example, log it alongside your X-Request-ID) so you can throttle before you hit the ceiling instead of reacting to 429s.

Exceeding the limit

When your organization exceeds its hourly limit, the API returns HTTP 429 with the standard error envelope and a Retry-After header:

HTTP/1.1 429 Too Many Requests
Retry-After: 842
Content-Type: application/json

{
  "error_code": "RATE_LIMITED",
  "detail": "Rate limit exceeded for this organization",
  "request_id": "b2f7c1e0-9a4d-4a5e-8f3a-1c2b3d4e5f60"
}

The error_code is RATE_LIMITED — see the status-to-error_code mapping in Errors & request IDs.

Retry-After semantics

Retry-After is the number of seconds until the current hour bucket resets:

• It is always present on a 429 response.
• Its value counts down to the top of the hour in UTC — for example, a 429 at 14:32:10 UTC reports roughly 1,670 seconds (until 15:00:00 UTC), not a fixed interval from the request.

Wait at least that long before sending another request. Requests sent before the bucket resets will also be rejected.

Backoff guidance

• Honor Retry-After. Resume sending when the header says the bucket has reset, not on your own schedule.
• Back off exponentially for other failures. For retries after network errors or 500 responses, use exponential backoff with jitter so a fleet of workers does not stampede the API at the same moment.
• Watch the remaining count. When X-RateLimit-Remaining approaches zero, slow down or defer non-urgent work until the next hour bucket.
• Do not fan out retries. If one request in a batch is limited, pause the batch — retrying in a tight loop only prolongs the 429s and burns the next bucket.

Next steps

• Errors & request IDs — the error envelope and RATE_LIMITED
• OpenAPI & API metadata — reading limits from GET /meta
• Authentication