Prototype · non-functional walkthrough
CCanon
RFC 014 — Public API Rate Limiting Draft · v3
YO
PK
MR
DN

RFC 014 — Public API Rate Limiting

Owners You, Marco Status In review Reviewers Priya, Dana
💬
1 · Summary

We are introducing rate limiting to the public API to protect shared infrastructure and ensure fair usage across customers. This document proposes the limiting strategy, the per-tier limits, and the rollout plan.

💬
2 · Limiting strategy 💬 1 open · Concern

Requests are counted and limited per client IP address. When a client exceeds its window, the API returns 429 Too Many Requests with a Retry-After header.

💬
2.1 · Per-tier limits
TierCounted perRequests / min
FreeIP60
ProIP600
EnterpriseIPCustom
💬
2.2 · Enforcement flow
client limiter api
🖼️ Architecture diagram · image blocks resolve to a manual replace, not an AI redraw
💬
3 · Rollout

Limits will be enabled in shadow mode for two weeks, logging would-be rejections without enforcing them. We then enforce for Free tier first, followed by Pro and Enterprise.

💬
4 · Open questions

How should we handle burst traffic for webhook retries? Should Enterprise customers be able to self-configure their own ceilings?

⚠ edited after decision — thread #38 was resolved, then this block was hand-edited
thread #42 · resolved
Why §2 says "per API key + IP backstop"
Priya: per-IP punishes shared-NAT customers. Dana: anonymous traffic has no key. Resolved (You, owner): per-key primary + coarse IP backstop.
Resolved Jun 1 · incorporated into §2, §2.1, §3
PK
DN
YO
Notifications
Your input was incorporated. Priya's concern on §2 shaped 3 sections of RFC 014.
just now · in-app + email
Marco approved an edit on PRD — Webhooks v2.
3h ago
Dana commented on §4 Open questions.
yesterday
Your input was incorporated
Priya's concern shaped §2, §2.1 and §3 of RFC 014.
Sent in-app + email · attributed to Priya, Dana, You
C
Skip the walkthrough
Click “Resolve thread” in the right panel to begin the loop▶ Replay tourReset