Skip to main content

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.

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.

Rate limit tiers

TierScopeLimitWindow
AuthenticatedPer merchant1,500 requests1 minute
Sensitive endpointsPer merchant10 requests1 minute
UnauthenticatedPer IP address100 requests1 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:
HeaderDescription
X-RateLimit-LimitMaximum requests allowed in the current window
X-RateLimit-RemainingRequests remaining in the current window
Retry-AfterSeconds to wait before retrying (only on 429 responses)

Rate limit error response

When you exceed the rate limit, the API returns a 429 status code:
{
  "error": {
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded",
    "message": "Too many requests. Please retry after the period specified in the Retry-After header.",
    "param": null,
    "doc_url": "https://docs.leanrails.com/guides/rate-limiting"
  }
}

Handling rate limits

Implement exponential backoff with jitter to handle rate limit responses gracefully:
# Check rate limit headers in the response:
curl -i https://api.leanrails.com/v1/payment_intents \
  -u "sk_test_xxx:"

# Look for:
# X-RateLimit-Limit: 1500
# X-RateLimit-Remaining: 1499
#
# On 429 responses, wait for the Retry-After duration:
# Retry-After: 30

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