Skip to main content

​
Rate Limiting

The Glider Platform API uses a two-layer rate limiting system to protect service availability while allowing legitimate traffic.

​
Two-Layer System

​
Layer 1: Global Per-IP Limit

Every request from a single IP address counts toward a global circuit breaker, regardless of which endpoint is called. This prevents any single client from overwhelming the service.

​
Layer 2: Per-Tier Per-IP Limits

Routes are grouped into tiers based on cost and sensitivity. All routes in the same tier share one counter per IP, preventing bypass by varying path parameters.
TierDescription
Tier 1 (critical)Expensive operations (e.g. LLM inference)
Tier 2 (general)Standard public endpoints
Tier 3 (burst)Read-heavy or cached endpoints
A request must pass both layers to succeed. If either the global or tier limit is exceeded, the request is rejected with a 429 status.

​
Response Headers

Every response from a rate-limited route includes standard rate limit headers:
HeaderDescription
X-RateLimit-LimitMaximum requests allowed in the current window
X-RateLimit-RemainingRequests remaining before the limit is reached
X-RateLimit-ResetUnix timestamp (seconds) when the window resets
Retry-AfterSeconds to wait before retrying (only on 429 responses)
When both layers apply, the headers reflect the tighter (per-tier) limit so clients can pace themselves accurately.

​
429 Response Format

When a rate limit is exceeded, the API returns: 
{
  "error": "Too Many Requests",
  "message": "Rate limit exceeded. Try again in 42 seconds.",
  "retryAfter": 42,
  "correlationId": "corr_abc123",
  "requestId": "req_xyz789"
}
FieldDescription
errorAlways "Too Many Requests"
messageHuman-readable description including wait time
retryAfterSeconds until the current window resets
correlationIdCorrelation ID for tracing across systems
requestIdUnique request identifier
Include the correlationId and requestId when contacting Glider support about rate limiting issues.

​
Retry Strategy

  1. Read the Retry-After header (or retryAfter field) from the 429 response.
  2. Wait at least that many seconds before retrying.
  3. Use exponential back-off with jitter if you receive repeated 429s.
  4. Avoid retry storms — stagger retries across clients when possible.