HTTP 402 vs 429: rate limiting vs paying to continue

Two HTTP status codes tell a client "not like this" — but for opposite reasons. 429 Too Many Requests says slow down. 402 Payment Required says pay up. For years the distinction was academic, because 402 was effectively unused and 429 did all the gatekeeping. That changed when APIs started charging per call. If you're deciding how to gate an endpoint in 2026 — especially against autonomous callers — knowing which code to return, and when, actually matters.

What's the difference between HTTP 402 and 429? HTTP 429 means the client sent too many requests in a window and should retry later — it's rate limiting, and the request is otherwise valid. HTTP 402 means the resource requires payment — the request is fine, but access is gated behind money the client must pay before retrying. 429 is about frequency; 402 is about payment.

402 vs 429 at a glance

The mnemonic: 429 is a clock problem, 402 is a wallet problem. Waiting fixes a 429. Waiting does nothing for a 402.

What 429 means

429 Too Many Requests is the status code for rate limiting. The client's request is legitimate; it has simply exceeded the number of requests the server will accept in a given window. It was introduced in RFC 6585 (2012) and carried into the current HTTP specification, RFC 9110.

A well-formed 429 usually includes a Retry-After header telling the client how long to wait before trying again. Rate limiting exists to protect the server from overload and to keep access fair across callers — it's an abuse-and-capacity control, not a billing one. A client that respects Retry-After and backs off will eventually get through at no cost.

What 402 means

402 Payment Required is the status code for payment. The request is well-formed and the caller is allowed to make it — but the resource costs money, and access is gated until the caller pays. It sat "reserved for future use" in the HTTP spec for decades (see the full HTTP 402 guide); in 2025–2026 the x402 protocol gave it a concrete meaning: a metered route answers an unpaid request with a signed 402 challenge quoting the exact price, the caller pays and retries, and the server verifies before serving.

The critical difference from 429: a 402 is not resolved by time. There's no Retry-After that helps. The caller has to do something new — pay — which is why a modern 402 carries a machine-readable price and a way to settle it, not just a "come back later."

The real question: quota vs price

Here's where the two codes actually collide in a design decision. The old model for metering an API was a free quota plus a 429: give each caller N requests per month, and once they exceed it, return 429 (or 403) until the window resets or they upgrade their plan. That works for human developers who signed up, picked a plan, and will wait for the reset.

The new model is a price plus a 402: instead of "you've used your 100 free calls, come back next month," the endpoint says "this call costs $0.002 — pay and continue now." For an autonomous agent running a task on a budget, that's a categorically better answer. A 429 tells the agent to stop and wait, which may kill the task; a 402 tells it exactly how to keep going. This is the same reason quota-and-plan models fit human developers but not agents — a point we cover in x402 vs API keys.

So the design question isn't "429 or 402?" as if you must pick one. It's "is the limit I'm enforcing about frequency or about payment?" — and the honest answer is often both.

They're not mutually exclusive

A robust API can return both, for different reasons, in a defined order:

1. Abuse and capacity first (429). Rate-limit every caller — paid or not — to protect the server. Even a paying agent shouldn't be able to hammer you 10,000 times a second. A 429 here says "you're paying, but slow down."
2. Payment second (402). For callers within the rate limit, gate the metered resource behind a 402 if it's unpaid.

The order matters: you don't want to quote a price to a caller you're about to rate-limit anyway. Check capacity, then check payment. A single request can legitimately receive a 429 on one attempt (too fast) and a 402 on the next (slowed down, but hasn't paid).

402 vs 429 vs 403 — the quick disambiguation

Since these get grouped together in "why is my request failing" searches, the one-liners:

• 402 Payment Required — allowed, but you must pay.
• 429 Too Many Requests — allowed, but too frequent; wait and retry.
• 403 Forbidden — not allowed, and neither waiting nor paying changes that.

If you're mapping status codes for a metered API, 403 is for "you can never do this," 429 is for "not this fast," and 402 is for "not until you pay." (For 402 against its closest neighbours 401 and 403, see the HTTP 402 guide.)

How to return a 402 (once you've decided it's the right code)

If the limit you're enforcing is about payment, not frequency, 402 is the correct code — and returning a useful one means quoting the price in the response, not just the status. That's what the x402 protocol standardizes: a signed challenge stating price, currency, and a nonce, so the caller can pay and retry without reading your docs.

You don't hand-roll that. With Paywall, you register a route and a price, add one middleware from the SDK for your stack, and unpaid calls get a signed 402 with the quote while paid calls pass through — humans and existing auth untouched. Keep your 429 rate limiting exactly where it is; the 402 layer sits alongside it. For choosing the actual number, see how to price an API for AI agents.

FAQ

Is 402 a replacement for 429? No. They solve different problems — 429 is rate limiting (frequency), 402 is payment. A metered API often uses both: 429 to protect capacity, 402 to charge for access.

Should I return 402 or 429 when a caller exceeds a free quota? It depends on what you want to happen next. Return 429 (or 403) if you want them to wait or upgrade a plan; return 402 if you want them to pay per call and continue immediately. For autonomous agents, 402 is usually the better fit because it lets the task proceed.

Does 402 use a Retry-After header? No. Retry-After is a 429 convention, because waiting resolves a rate limit. A 402 isn't resolved by waiting — it carries a payment challenge (price, currency, nonce) instead, because the caller must pay, not wait.

Can one request get both a 429 and a 402? Yes, on different attempts. A too-fast request gets a 429; once the caller slows down, an unpaid request to a metered resource gets a 402. Check capacity first, then payment.

Which spec defines each? 429 was introduced in RFC 6585 (2012) and is now part of RFC 9110. 402 is defined in RFC 9110, §15.5.3, where it was long "reserved for future use" before protocols like x402 gave it concrete behaviour.

Next steps

• The full picture on the payment code: HTTP 402 Payment Required
• Why quota-and-plan models don't fit agents: x402 vs API keys
• Return a real 402 from your API: for developers · the nine SDKs
• Test the whole loop first: how to test x402 payments
• Ready to try it: create an account