Skip to main content

Rate Limiting Policies

To ensure platform reliability, backend resource availability, and protection against malicious traffic spikes, Glow Prow enforces dynamic multi-tiered rate limiting policies across all public API endpoints.

Tiered Throttling Architecture​

Our rate limiting infrastructure adaptively evaluates requests based on operation complexity, resource load, and client credentials:

  • Read & Query Endpoints: Generous baseline quotas are allocated for high-frequency data fetching (e.g., assembly searches, drops lists, map points) to ensure responsive client UI rendering.
  • Write & Mutation Endpoints: Stricter adaptive rate limits are enforced for state-modifying actions such as assembly publishing, collection creation, and profile updates.
  • Sensitive & High-Cost Operations: Operations involving password verification, login, image rendering, or captcha generation are protected by tight safety windows to guard against brute-force attempts and computational overload.
  • Multi-Dimensional Tracking: Limits are computed across client IP addresses, authentication bearer tokens, and application identifiers.

Rate Limit Response Headers​

Each HTTP response includes rate limit metadata reflecting your current sliding window:

Response HeaderDescription
X-RateLimit-LimitMaximum allowed requests within the current time window
X-RateLimit-RemainingRemaining requests available in the current window
X-RateLimit-ResetUnix timestamp (in seconds) when the quota window resets

Example Response Headers​

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
X-RateLimit-Limit: 120
X-RateLimit-Remaining: 98
X-RateLimit-Reset: 1774932000

Handling Throttled Responses​

When request volume exceeds the allocated window quota, the API rejects subsequent calls with an HTTP 429 Too Many Requests response:

{
  "code": 429,
  "message": "Too many requests, please slow down and try again later",
  "data": {
    "retryAfter": 15
  }
}

The response includes a Retry-After header indicating the number of seconds to back off before retrying.

Client Integration Best Practices​

  • Leverage Client-Side Caching: For slow-changing data (e.g. codex items, war history archives, guide images), maintain a local cache (5 minutes to 3 hours) to avoid redundant requests.
  • Implement Exponential Backoff: Upon receiving an HTTP 429 response, parse the Retry-After header and apply exponential backoff with jitter before reattempting the request. Avoid busy retry loops.
  • Throttle Paginated Batch Queries: When scraping or batch-fetching pages, introduce minor spacing delays between consecutive network calls.
  • Use Authenticated User Sessions: Authenticated user tokens receive higher baseline quotas suitable for interactive integrations.