How to Implement API Rate Limiting: Protect Your AI-Built App Before Someone Hammers It

Why AI Coders Need This

You asked AI to build an API. It created beautiful endpoints — user registration, data fetching, maybe even an AI-powered feature that calls OpenAI. It all works. Ship it.

But your AI didn't add rate limiting. Here's what happens next:

• A bot finds your login endpoint and tries 50,000 password combinations in an hour
• Someone discovers your /api/generate endpoint and burns through $200 of OpenAI credits overnight
• A user's broken frontend script sends the same request 100 times per second, crashing your database
• A competitor's scraper downloads your entire content library in 10 minutes

All of these are real scenarios that happen to unprotected APIs every day. Rate limiting is the seatbelt of API development — you don't think about it until you need it, and by then it's too late.

What AI Generated: Express Rate Limiting

Here's the typical output when you ask AI to add rate limiting to an Express app:

// middleware/rateLimiter.js
import rateLimit from 'express-rate-limit';

// General API rate limit: 100 requests per minute
export const apiLimiter = rateLimit({
  windowMs: 60 * 1000,       // 1 minute
  max: 100,                   // 100 requests per window
  standardHeaders: true,      // Return rate limit info in headers
  legacyHeaders: false,       // Disable X-RateLimit-* headers
  message: {
    error: 'Too many requests',
    message: 'Please try again in a minute',
    retryAfter: 60
  }
});

// Strict limit for auth endpoints: 10 per minute
export const authLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 10,
  message: {
    error: 'Too many login attempts',
    message: 'Please try again in a minute',
    retryAfter: 60
  }
});

// Usage in your Express app:
// app.use('/api/', apiLimiter);
// app.use('/api/auth/', authLimiter);

This is actually pretty good. But let's understand each piece so you know what to change.

Understanding Each Part

windowMs — The Time Window

This is how long the counter runs before resetting. 60 * 1000 means 60,000 milliseconds = 1 minute. After each minute, everyone's counter resets to zero. Common windows:

• 1 minute (60 * 1000) — most common for API endpoints
• 15 minutes (15 * 60 * 1000) — common for auth endpoints
• 1 hour (60 * 60 * 1000) — for expensive operations like AI generation

max — The Request Limit

How many requests one client can make during the window. When they hit this number, all subsequent requests get a 429 Too Many Requests response until the window resets.

standardHeaders — Tell Users Their Limits

When true, every response includes headers like:

RateLimit-Limit: 100
RateLimit-Remaining: 73
RateLimit-Reset: 1711382460

This tells the client: "You have 100 requests per window, 73 remaining, and the window resets at this Unix timestamp." Good API citizenship.

IP-Based vs User-Based Limiting

By default, express-rate-limit uses the IP address. This works for most cases, but has a catch: users behind the same corporate VPN or coffee shop WiFi share an IP. For authenticated endpoints, you want to limit by user ID instead:

const userLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 100,
  keyGenerator: (req) => {
    // Use user ID if authenticated, fall back to IP
    return req.user?.id || req.ip;
  }
});

Rate Limiting in Next.js and Serverless

express-rate-limit stores counters in memory — which breaks on serverless platforms like Vercel because each function invocation is a separate instance with no shared memory.

For serverless, use Upstash Ratelimit — it stores counters in Redis (Upstash provides a serverless Redis):

// lib/ratelimit.js
import { Ratelimit } from '@upstash/ratelimit';
import { Redis } from '@upstash/redis';

export const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(100, '1 m'),
  analytics: true,
  prefix: 'api',
});

// Usage in a Next.js API route:
// app/api/generate/route.js
import { ratelimit } from '@/lib/ratelimit';
import { headers } from 'next/headers';

export async function POST(request) {
  const headersList = headers();
  const ip = headersList.get('x-forwarded-for') ?? '127.0.0.1';

  const { success, limit, remaining, reset } = await ratelimit.limit(ip);

  if (!success) {
    return Response.json(
      { error: 'Rate limit exceeded' },
      {
        status: 429,
        headers: {
          'RateLimit-Limit': limit.toString(),
          'RateLimit-Remaining': remaining.toString(),
          'RateLimit-Reset': reset.toString(),
          'Retry-After': Math.ceil((reset - Date.now()) / 1000).toString(),
        }
      }
    );
  }

  // ... your actual API logic
}

What Endpoints to Protect (Priority Order)

Endpoint Type	Why	Suggested Limit
Login / Signup	Brute force prevention	5-10 / minute
Password Reset	Email bombing prevention	3-5 / hour
AI/LLM Calls	Cost protection ($$$)	10-20 / hour
Payment Endpoints	Fraud prevention	5-10 / minute
File Uploads	Storage/bandwidth abuse	10-20 / hour
Search / Query	Database protection	30-60 / minute
General API	Overall protection	100-200 / minute

Start with auth and AI/LLM endpoints. Those are the highest-risk targets. A brute-forced login or an abused OpenAI endpoint can cost you money or compromise your users immediately.

What AI Gets Wrong About Rate Limiting

How to Test Your Rate Limiting

Don't ship rate limiting without testing it. Here's a quick way to verify:

# Send 15 rapid requests to your auth endpoint
for i in $(seq 1 15); do
  echo "Request $i: $(curl -s -o /dev/null -w '%{http_code}' \
    -X POST http://localhost:3000/api/auth/login \
    -H 'Content-Type: application/json' \
    -d '{"email":"test@test.com","password":"test"}')"
done

# Expected output (with 10/min limit):
# Request 1-10: 200 (or 401)
# Request 11+: 429

If you see 429 responses after hitting your limit, it's working. If every request returns 200, your rate limiting isn't applied — check your middleware order.

Rate Limiting Tools Compared

Tool	Best For	Storage	Free Tier
express-rate-limit	Express apps on traditional servers	In-memory (or Redis with adapter)	Open source
Upstash Ratelimit	Next.js, Vercel, serverless	Upstash Redis	10K requests/day
Cloudflare Rate Limiting	Edge-level protection	Cloudflare edge	1 rule free
Vercel Firewall	Vercel-hosted apps	Vercel edge	Pro plan
Redis + custom	Full control, any platform	Redis	Depends on Redis host

Recommendation for most vibe coders: Use express-rate-limit for Express apps and Upstash for Next.js/serverless. Add Cloudflare on top for DDoS protection if your app gets real traffic.

Frequently Asked Questions