Interaction of per-user and per-IP rate limits in Weblate API

Question

Determine how Weblate applies rate limits when both per‑user and per‑IP thresholds are configured. The built‑in API rate‑limiting feature uses the WEBLATE_RATE_LIMIT setting and returns standard headers, but the documentation does not state whether the two limits are evaluated independently or if the more restrictive limit is enforced. This ambiguity affects automation scripts and CI pipelines that may rely on predictable throttling behavior.

Clarify the combined behavior to predict when a request will receive HTTP 429 and which header values reflect the remaining quota. Specifically: Does Weblate treat per‑user and per‑IP limits as separate counters that must both be exceeded before blocking? If a request exceeds either limit, is it immediately rejected? When both limits are exceeded, which limit’s X‑RateLimit‑Remaining and X‑RateLimit‑Reset values are returned?

Tasadduq Burney · Answer

Combined Rate Limit Behavior
In Weblate, per-user and per-IP rate limits are evaluated as independent counters. A request is rejected with an HTTP 429 (Too Many Requests) if either limit is exceeded. They are not additive, nor must both be exceeded to trigger a block; the most restrictive limit currently applicable to the request wins.

Likely Implementation Logic
Weblate leverages Django REST Framework (DRF) for its throttling mechanisms. Based on DRF's standard behavior, the process follows these steps for every incoming API request:

The system identifies all applicable throttle scopes (e.g., user and anon/ip).
Each scope maintains its own separate counter in the cache, keyed by the user ID or the client IP address.
The request is checked against every active scope. If any single check returns a failure, the request is immediately blocked.

Impact on Headers and CI Pipelines
When a request is throttled, the X-RateLimit-Remaining and X-RateLimit-Reset headers typically reflect the state of the specific throttle that triggered the block. If both limits are exceeded simultaneously, the headers will generally correspond to the first throttle class evaluated by the framework.

This behavior is particularly critical for CI/CD pipelines. If multiple automation scripts share a single egress IP (common in GitHub Actions or GitLab CI), they may trigger the per-IP limit even if each individual script uses a unique API key with a generous per-user quota.

Verification Steps
To confirm the behavior on your specific Weblate version, you can perform the following scoped tests:

Test IP Isolation: Use multiple authenticated accounts from a single IP. If requests are blocked while individual user quotas are still high, the per-IP limit is the bottleneck.
Header Analysis: Trigger a 429 and check the Retry-After header. Compare this value against the expected reset time of your user-specific quota versus the IP-specific quota.
Configuration Audit: Review your WEBLATE_RATE_LIMIT settings to ensure the anon or ip scopes are not set too aggressively for your infrastructure's NAT configuration.

Required Diagnostic Detail: To provide a more precise answer regarding header attribution, please specify the Weblate version you are running, as throttling header logic has evolved across releases.

Interaction of per-user and per-IP rate limits in Weblate API

1 answer

Combined Rate Limit Behavior

Likely Implementation Logic

Impact on Headers and CI Pipelines

Verification Steps

Your perspective belongs here.

0 question comments