Context: Grant milestone requires a public REST API -- the existing rate-limit config (RPC_RATE_LIMIT_REQUESTS_PER_MINUTE etc.) governs outbound Stellar RPC calls, not inbound public API consumers. This is a different limiter.
Where:
src/rate_limit.rs, src/api_keys.rs (existing API key infra)
What to do:
- Define a public-tier rate limit for unauthenticated/API-key-only consumers of the new analytics endpoints, distinct from internal/authenticated traffic.
Suggested approach:
- Check
src/api_keys.rs for existing API-key-based auth/tiering before building a new mechanism.
- Define a public tier limit distinct from internal traffic -- likely lower requests-per-minute than the existing
RPC_RATE_LIMIT_* config, which governs outbound calls, not inbound.
- Return a clear 429 with a
Retry-After header when the limit is hit, matching whatever convention src/rate_limit.rs already uses elsewhere.
Watch out for:
- Don't accidentally rate-limit authenticated/internal traffic under the new public tier -- make sure the tiering logic actually distinguishes the two before this ships.
Definition of done:
Context: Grant milestone requires a public REST API -- the existing rate-limit config (
RPC_RATE_LIMIT_REQUESTS_PER_MINUTEetc.) governs outbound Stellar RPC calls, not inbound public API consumers. This is a different limiter.Where:
src/rate_limit.rs,src/api_keys.rs(existing API key infra)What to do:
Suggested approach:
src/api_keys.rsfor existing API-key-based auth/tiering before building a new mechanism.RPC_RATE_LIMIT_*config, which governs outbound calls, not inbound.Retry-Afterheader when the limit is hit, matching whatever conventionsrc/rate_limit.rsalready uses elsewhere.Watch out for:
Definition of done: