Rate Limiting

Rate limiting doesn't make an action impossible — it makes it too slow to be worth doing. Capping login attempts, API calls, or password resets per identity per time window is what turns brute force from "seconds" into "centuries."

Limiting by IP alone is easily defeated by rotating through proxies — limiting by account/identity closes the gap that IP-only limits leave open

A limit that's too generous barely slows an automated attacker; a limit that's too strict locks out real users on shared networks (offices, campuses, mobile carrier NAT)

Exponential backoff (each failure waits longer than the last) punishes sustained abuse more than a flat per-minute cap does

Rate limiting is a mitigation, not a fix — it buys time and raises cost, but a genuinely broken authorization check still needs to be fixed directly

Hands-on demo

Run a credential-stuffing script

Fires a leaked password list against the login endpoint as fast as it can — watch the backoff kick in.

Launch the script above to see the backoff escalate.

Try it yourself

Try it yourself — run a scenario below, then flip this and replay it to see what changes.

Normal API Usage

A legitimate integration stays comfortably under the limit.

Want this flow explained in detail as it plays?

api.flowground.dev

Partner API

Rate1 request / few seconds

Partner Integration

App

One request every few seconds, well under the configured limit of 100 requests/minute per API key.

Selected hop

Partner integration polls the orders API

Partner Integration

A well-behaved third-party client consuming the API within its rate limit.

App

The application's backend — enforces business rules and decides what every request is allowed to do.

What happens here

One request every few seconds, well under the configured limit of 100 requests/minute per API key.