# Rate limiting when your buyer is an agent

With x402 every request is paid before it is served, so volumetric abuse is self-limiting: an attacker's worst case is buying a lot of your product at your price. The limits still worth having are on unpaid 402 traffic, on concurrency per payer, and on the facilitator calls your own server makes.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/rate-limiting-when-your-buyer-is-an-agent

---

## What changes when every request is prepaid?

Behind a free tier or an API key, the expensive attack is someone extracting a lot of value for nothing: a leaked key, a scripted free tier, a scraper working through your corpus.

With x402, every served request was paid for before it was served. So the equivalent attack is somebody buying a lot of your product at the price you set, which is not an attack. It is your business working.

That removes most of the reason free-tier rate limiting exists, and it leaves three places where limits still earn their keep.

## 1. Unpaid traffic

The one real exposure. A 402 response costs you something to produce: a request parsed, terms built, possibly a price looked up. None of it is paid for, because the whole point of a 402 is that it precedes payment.

An attacker that sends a hundred thousand unpaid requests costs you a hundred thousand 402s and pays nothing. That is cheap to send and not free to serve.

**Limit unpaid requests per source address, generously.** A legitimate buyer sends one 402-triggering request and then pays. A client probing your price list sends a few. Anything sending thousands without ever paying is not a buyer.

Keep the limit well above normal behaviour, since legitimate clients do probe, and make the 402 cheap to produce: static terms, no database lookup per request where you can avoid it.

## 2. Concurrency per payer

Not a volume limit, a shape limit.

A single payer opening hundreds of simultaneous expensive requests can exhaust your capacity even though every one of them is paid. You will be fully compensated and your other customers will see timeouts.

**Cap concurrent in-flight requests per payer address.** This is about protecting your service from a legitimate buyer with a very parallel workload, which agent buyers genuinely have.

| Limit | Protects against | Set it |
| --- | --- | --- |
| Unpaid 402s per source | Free 402 flooding | Generously, but finite |
| Concurrent requests per payer | Capacity exhaustion by one buyer | Near your per-tenant capacity |
| Your own facilitator calls | Exhausting a metered dependency | Below your facilitator quota |
| Total in-flight expensive work | Everything at once | At your actual capacity |

## 3. What about your own outbound calls?

The limit people forget, and the one that produces the worst outage.

Your server calls a facilitator to verify and settle. That facilitator is metered, rate limited, or both. Under a traffic spike your own verification calls can exhaust your facilitator quota, at which point **legitimate paid requests start failing because of load you were being paid for.**

Limit your outbound facilitator calls below your quota, queue rather than drop when you hit the ceiling, and alert on approach rather than on exhaustion.

> [!WARNING]
> This failure is self-inflicted and looks external. Your logs show the facilitator refusing you; the facilitator's show you exceeding your allowance. The symptom is payment failures during your best traffic, which is the worst possible time for it.

## Why address-based limiting is weak

Because addresses are free to create. A determined attacker rotates them and your per-address limit becomes per-request.

This matters less than it would elsewhere, because the thing you are protecting is unpaid 402 traffic rather than your product. An attacker rotating addresses to send more unpaid requests is spending effort to cost you 402 responses, which you have already made cheap.

If you need stronger limits than addresses support, you need identity, and identity means keys. That is a reason to run both paths rather than a reason to distrust x402: let a payment mint a key, and limit the keyed path properly. [Keys against x402](https://roundhouseai.io/resources/x402-vs-api-keys-and-metered-billing) covers the pattern.

## What about agents that retry badly?

Common, and worth handling as an operational fact rather than as abuse.

An agent that gets a 402 and does not know how to pay will often retry immediately, repeatedly. It is not attacking you; it is failing in a loop. The response is a `Retry-After` header on your 402 and a clear enough error body that a competent client stops.

Make the refusal actionable. A 402 with full terms tells a capable client exactly what to do. A bare 402 tells it nothing, so it tries again, which is a loop you created.

## Frequently asked questions

### Should I rate limit paid requests at all?

By concurrency, not by volume. A buyer paying for more calls is the outcome you want; a buyer monopolising capacity is not.

### How do I limit by payer before the payment is verified?

You can read the payer from the payment header before verifying, and you should treat it as unverified until it is. For concurrency limiting that is adequate, because an attacker forging a payer address to lower its own limit is working against itself.

### Does a free tier still make sense alongside x402?

Yes, hard limited, for evaluation. A buyer that cannot see your output quality before paying often will not pay. Keep it small and keep it limited.

### What about crawlers?

They will hit your free paths and your 402s and will not pay. That is fine and expected, and it is the main reason the unpaid-request limit exists.

### Should I block addresses?

Rarely. It is cheap to evade and you will mostly block the wrong things. Limit rather than block, and reserve blocking for a specific, repeated, identified problem.

## Where to check this yourself

[Errors](https://roundhouseai.io/docs/x402/errors) documents the refusal responses, including which ones carry `Retry-After` and what a client should do with each. For the capacity side, [the publishing checklist](https://roundhouseai.io/resources/publish-an-x402-service-checklist) covers the conversion and failure metrics worth watching once you are taking real traffic.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api