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)

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.

Powered by Blend

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.