RATE_LIMIT_MAX=200 and RATE_LIMIT_WINDOW=60000 (200 requests per minute); operators can change both within the validated deployment range.
Sensitive handlers add stricter Redis-backed fixed windows per IP and route. Current examples include:
Authentication routes have separate brute-force throttling. Payment webhooks use a provider/shop flood guard while retaining the provider’s retry semantics.
When a limit is exceeded, the API responds with
429 Too Many Requests. Clients must back off and should add jitter instead of retrying immediately.
Redis shares sensitive-endpoint counters across API instances. If Redis is temporarily unavailable, each instance keeps a bounded in-memory fallback so brute-force protection is not disabled; counters are then conservative per instance until Redis recovers.