API calls are rate limited. That's normal, and a well-written client barely notices it: the platform reports how much allowance you have left on the responses it measures, and tells you exactly how long to wait when you run out.

This guide is about your account. It covers the limits that apply to your keys, where to watch what's left, how to find the calls that were refused, and how to pace an integration so it stays clear of its limits.

The wire contract lives in the rate limits reference. That page states a refused request in full: the status it returns, the response headers it carries, the body it sends, and what to build a client against. It needs no account, so you can read it before you sign up and hand it to whoever writes your integration. This guide doesn't restate it.

What applies to your keys

Limits are applied per API key, over the API surface at /api. Every key gets its own allowance, so one busy integration can't spend another's.

The ceiling is tuned per deployment and per account, so no fixed number is published. Design for the refusal rather than for a specific figure and your integration stays correct wherever it runs, and stays correct after somebody raises your limit.

You don't have to guess what applies to you. The developer portal shows the current number for each of your keys, along with how much of it you've used in the window you're in right now, at Rate limits in the portal navigation. If you need more headroom, ask your integration contact: a limit can be raised for a single key without a code change or a deploy on your side.

How the window moves

The allowance is measured over a sliding window rather than a fixed one. A fixed window would let a caller spend a whole allowance in the last second of one window and a whole allowance in the first second of the next, so the real short-term ceiling would be twice the configured number. A sliding window means the figure the portal shows you is the figure that applies.

A refused request still counts against the window. Retrying immediately doesn't get you back under the limit sooner: it spends more of the allowance you've already run out of. This is deliberate, and it's why the backoff below matters.

Finding your limited calls

Refused calls appear in your request log like any other, with status 429. The portal's Rate limits page counts them over the last 24 hours, 7 days, and 30 days, and each count links straight into the request log narrowed to those calls, so you can see which endpoints and which keys ran out of allowance.

If the counts are climbing and you haven't changed how much you send, the usual cause is a retry loop that isn't honoring the wait the platform asks for: every premature retry adds another refusal to the count and another request to the window.

Backing off correctly

What a good client does when it's refused:

• Wait at least as long as the platform asks before retrying. The refusal carries the interval, and the rate limits reference shows where to read it. Retrying sooner is refused again, and the refused call spends more of your window.
• Back off exponentially past the first retry, with a little random jitter, so a fleet of workers that all got limited at once doesn't come back in lockstep and limit itself again.
• Cap the number of retries and surface a failure rather than looping forever.
• Pair retries of a create with an idempotency key, so a retry that turns out to have been unnecessary replays the original result instead of charging again. Getting started with the API covers idempotency in full.
• Watch your remaining allowance and slow down before it reaches zero if you control the pace of your own work. A response that a limit measured reports what's left, and one that no limit covered reports nothing at all rather than zero. A queue-driven integration that spends its allowance evenly never meets a refusal at all.

Treat a refusal as normal operating feedback rather than as an error condition. It's the platform asking you to pace yourself, and it says exactly how.

What's not limited this way

These limits cover the API at /api, authenticated with an API key. The hosted payment page, the portal itself, and the platform's sign-in surfaces have their own protections, which aren't the ones described here and don't consume your key's allowance.