Rate limiting checklist

Generated apps often leave every route open at full speed. That becomes a bill when a route calls a model, sends email, or creates accounts. A disabled button does not stop a request someone sends with curl.

Routes that usually need a limit

• Sign-up, login, and password reset. These are used for credential stuffing and inbox spam.
• Any route that calls a paid API: chat completions, image generation, embeddings, search.
• Checkout creation and webhook-adjacent endpoints. A limit is not a substitute for webhook verification, but it cuts noise.
• Public form posts and anything that sends email.

Where the limit has to live

• Enforce it on the server or at the edge, before the expensive call. A check only in React state is optional for the caller.
• Key the limit on something a stranger cannot mint forever. A user id works for signed-in routes. For anonymous routes, an IP is a rough key and a poor one behind shared networks. Say so in your own notes if you use it.
• Return a clear 429 when the limit hits, and do not still perform the side effect.

Ways people implement it

• The host’s firewall or WAF, if you are on a platform that has one and you have turned the rule on.
• A small store with a TTL, such as a Redis-compatible counter, checked at the start of the route.
• A durable workflow tool when the work itself should be queued rather than limited. A queue is not a rate limit unless you also cap how fast it runs.

Check that it works

• Send more requests than the cap, from outside the UI, and confirm the expensive provider was not called on the extra attempts.
• Confirm a normal user can still complete one signup or one generation.
• Log the 429s somewhere you will see them. A silent drop looks like a bug.

Not a guarantee. Limits reduce abuse. They do not identify attackers, and a determined client can still cost you money under the cap. This is a checklist, not a threat model.