Rate limits on public endpoints

Paste into any coding agent: Claude Code, Cursor, Codex, Copilot, Windsurf or Cline.

# Rate limits on public endpoints

When the production site launches, the same publicity that brings users brings scrapers, spam bots and the occasional angry script. Endpoints that send email, call paid APIs, run searches or accept uploads can run up a bill or fall over. Put sensible limits on them, using one shared mechanism.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Add a paid service without asking.
- Rate limit webhooks from payment providers in a way that drops events.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. List the endpoints worth limiting

List every public route that accepts input or does expensive work: auth, contact and feedback forms, newsletter sign-up, search, uploads, webhooks, AI or other paid API calls, exports. For each, note the cost of one call and who should be allowed to call it.

### 2. One limiter, shared

Reuse a rate limiter if the project has one. If not, propose one that works on the current host across instances (a key-value store, Redis, the database, or the platform's rate limiting), not an in-memory counter that resets per instance. Key limits by IP for anonymous traffic and by account for signed-in traffic.

### 3. Set the limits

Pick limits per endpoint that a real person never hits (for example 5 password resets an hour, 30 searches a minute) and that stop a script. Answer over-limit requests with 429 and a `Retry-After` header, and show a friendly message in the UI rather than a raw error.

### 4. Make it observable

Log when limits trip (endpoint, key type, not personal data) so I can see attacks and tune limits. Add a test for at least one limited endpoint.

## Done means

- [ ] Every endpoint that sends email, calls a paid API, searches or accepts uploads is rate limited.
- [ ] Limits work across instances, keyed by IP or account.
- [ ] Over-limit requests get 429 with Retry-After and a friendly message in the UI.
- [ ] Tripped limits are logged, and a test covers one limited endpoint.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.