Rate limiting your SaaS API before launch: a practical guide
No rate limit means one bad actor or bot can crash your app. Here is how to implement and verify rate limiting before real traffic arrives.
Rate limiting is the most overlooked launch requirement. Without it, a single bot, scraper, or curious user can exhaust your API quota, crash your database connection pool, burn through your email sending limit, or trigger provider rate limits that affect all users. The time to implement rate limiting is before launch, not after the incident.
What endpoints need rate limiting
Priority endpoints for rate limiting: authentication (login, signup, password reset), payment creation, API key generation, email/SMS sending triggers, file uploads, and any endpoint that performs expensive database queries. Public API endpoints need stricter limits than authenticated ones.
Rate limiting strategies
Fixed window (simple, bursty), sliding window (smoother), and token bucket (flexible with burst allowance) are the three main approaches. For most SaaS APIs, sliding window with IP-based limiting for unauthenticated routes and user-based limiting for authenticated routes covers the critical paths.
Return proper error responses
When a limit is hit, return 429 Too Many Requests with a Retry-After header. Do not return 500 or 403 — clients need to know the difference between "you are blocked" and "you need to wait." Include rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset) so clients can implement backoff without trial and error.
Verify limits are active
Configuration is not verification. After implementing rate limits, test them: send requests above the threshold and confirm you receive 429 responses with correct headers. PreFlight's Launch Checklist probes rate limiting behavior on your public endpoints and flags missing or misconfigured limits before launch traffic arrives.