The API enforces rate limits to ensure fair usage and protect infrastructure. Limits are applied per merchant for authenticated requests and per IP address for unauthenticated requests.Documentation Index
Fetch the complete documentation index at: https://docs.fluveo.com/llms.txt
Use this file to discover all available pages before exploring further.
Rate limit tiers
| Tier | Scope | Limit | Window |
|---|---|---|---|
| Authenticated | Per merchant | 1,500 requests | 1 minute |
| Sensitive endpoints | Per merchant | 10 requests | 1 minute |
| Unauthenticated | Per IP address | 100 requests | 1 minute |
Sensitive endpoints
The following endpoints have stricter rate limits due to their security-sensitive nature:/v1/api_keys— API key management
Rate limit headers
Every API response includes headers to help you track your usage:| Header | Description |
|---|---|
X-RateLimit-Limit | Maximum requests allowed in the current window |
X-RateLimit-Remaining | Requests remaining in the current window |
Retry-After | Seconds to wait before retrying (only on 429 responses) |
Rate limit error response
When you exceed the rate limit, the API returns a429 status code:
Handling rate limits
Implement exponential backoff with jitter to handle rate limit responses gracefully:Best practices
Distribute requests evenly. Avoid sending large bursts of requests. Spread API calls over time to stay within limits.
- Cache responses when possible to reduce unnecessary API calls
- Use exponential backoff with jitter to avoid thundering herd problems when retrying
- Monitor rate limit headers to proactively throttle before hitting limits
- Use idempotency keys so retried requests don’t create duplicate resources