Problem
The API applies token-bucket rate limiting with tiers (src/middleware/tokenBucket.ts, src/middleware/apiKeyAuth.ts, including a rateLimitOverride), but the tier limits are defined in code, there is no documentation of the tiers, and it is unverified whether responses return standard rate-limit headers (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset, Retry-After) that clients need to back off correctly.
What needs to be done
- Make each tier's limit and window configurable via environment variables with the current values as defaults.
- Emit standard rate-limit headers on responses, and
Retry-After on 429s.
- Document the tiers, their limits, and the override mechanism in the README.
- Add tests asserting that a client exceeding its tier receives a
429 with the correct headers.
Files
src/middleware/tokenBucket.ts, src/middleware/apiKeyAuth.ts
.env.example, README.md
Acceptance deliverables
- Tier limits are env-configurable and documented.
- Responses carry standard rate-limit headers;
429s include Retry-After.
- All CI checks pass; the change cannot be merged until CI is green.
Tests to pass
- Test: exceeding a tier returns
429 with Retry-After and the rate-limit headers.
- Test: within-limit requests include the remaining-quota header.
Problem
The API applies token-bucket rate limiting with tiers (
src/middleware/tokenBucket.ts,src/middleware/apiKeyAuth.ts, including arateLimitOverride), but the tier limits are defined in code, there is no documentation of the tiers, and it is unverified whether responses return standard rate-limit headers (RateLimit-Limit,RateLimit-Remaining,RateLimit-Reset,Retry-After) that clients need to back off correctly.What needs to be done
Retry-Afteron429s.429with the correct headers.Files
src/middleware/tokenBucket.ts,src/middleware/apiKeyAuth.ts.env.example,README.mdAcceptance deliverables
429s includeRetry-After.Tests to pass
429withRetry-Afterand the rate-limit headers.