Rate limits

Limits are per minute and counted per credential, your channel key for server-to-server calls, the buyer’s session for calls made inside a webview. They are set so that normal traffic never reaches them.

The headroom is deliberate: reading the catalog is cheap and generous, while the calls that move money are tighter, because a runaway retry loop on those is the one that costs somebody real money.

Server-to-server (per channel key)

Endpoint	Per minute	Notes
GET /channel/events	600	Catalog reads, including detail.
POST /channel/orders/status	300	Polling a single order.
POST /channel/events/:id/checkout	60	Reserving an order.
POST /channel/orders/confirm	60	Confirming a charge.
POST /channel/session	60	Minting buyer sessions.

Inside a buyer session (per session)

These apply to the webview, which is Blend’s own code, you do not normally need to think about them. They are listed because a CTO reviewing the design will want to see that a single buyer cannot exhaust a shared budget.

Surface	Per minute
Session resolve	300
Catalog inside a session	300
Seat map reads and holds	600
Order status polling	120
Checkout	60

Staying under them

Three habits are enough:

Do not poll the catalog. It changes when a Blend administrator changes it, not continuously. Fetching it when a user opens your events tab is the right cadence; a background sync every few seconds is not.
Poll one order, not all of them. Order status is per order and the webview already polls the buyer’s own. Your backend generally does not need to poll at all, it knows the outcome of its own charge.
Back off on failure. If a call fails, wait before retrying, and for anything that moves money, retry with the same idempotency key rather than a new one, so a retry can never become a second order.

If you need more

Limits are per key and can be raised for a partner with a known traffic profile. Tell Blend the expected peak, an on-sale for a large event is a legitimate reason and is better arranged in advance than discovered at 10am on the day.

ErrorsEvery status and code, and the right response to each.Reserving an orderWhere idempotency keys belong.

Rate limits

The headroom is deliberate: reading the catalog is cheap and generous, while the calls that move money are tighter, because a runaway retry loop on those is the one that costs somebody real money.

Endpoint

Per minute

Notes

GET /channel/events

600

Catalog reads, including detail.

POST /channel/orders/status

300

Polling a single order.

POST /channel/events/:id/checkout

Reserving an order.

POST /channel/orders/confirm

Confirming a charge.

POST /channel/session

Minting buyer sessions.

Inside a buyer session (per session)

Surface	Per minute
Session resolve	300
Catalog inside a session	300
Seat map reads and holds	600
Order status polling	120
Checkout	60

Staying under them

Three habits are enough:

Do not poll the catalog. It changes when a Blend administrator changes it, not continuously. Fetching it when a user opens your events tab is the right cadence; a background sync every few seconds is not.

Poll one order, not all of them. Order status is per order and the webview already polls the buyer’s own. Your backend generally does not need to poll at all, it knows the outcome of its own charge.

Back off on failure. If a call fails, wait before retrying, and for anything that moves money, retry with the same idempotency key rather than a new one, so a retry can never become a second order.

If you need more