Rate limits

GetFluxly enforces per-key rate limits on every public endpoint. Limits are project-tier-dependent and surface to the caller through standard headers.

Headers

Every successful response carries:

X-RateLimit-Limit:     1000
X-RateLimit-Remaining: 873
X-RateLimit-Reset:     1715846400

X-RateLimit-Reset is Unix epoch seconds at which the window rolls over.

When you exceed the bucket

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

{
  "error": "rate_limited",
  "detail": "Per-key burst exceeded. Retry after 2 seconds."
}

The SDKs honor Retry-After automatically, including 408, 425, 429, and 5xx with exponential backoff and ±25% jitter. If you're hitting the rate limit from your own integration, mirror that behavior: sleep Retry-After seconds, then retry with the same X-Idempotency-Key so a duplicate payload doesn't get double-counted.

Tier defaults

| Tier | Events/sec | Burst | | --- | --- | --- | | Free | 50 | 100 | | Pro | 500 | 1000 | | Enterprise | Negotiated | Negotiated |

Limits are per key, not per project, generating additional keys does not multiply your allowance. Contact support for sustained workloads that need more.