Rate limits

Each key may make a fixed number of requests per minute, counted in one-minute windows on the key itself:

Mode	Requests per minute
Live	600
Sandbox	120

Per key, so a checkout and a reconciliation script on separate keys do not compete — which is one more reason to give each server its own key.

Headers

Every authenticated response carries three headers:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 598
X-RateLimit-Reset: 1758100860

X-RateLimit-Reset is the unix time, in seconds, when the window resets. Over the limit, the answer is RATE_LIMITED (429) with a fourth header:

Retry-After: 23

Wait that many seconds and send the same request. Nothing was taken.

Pacing a batch

A job that walks four hundred bills should read X-RateLimit-Remaining on each response and pause when it nears zero, rather than wait to be refused. A refusal is harmless — it is a 429, nothing happened — but a client that plans around the headers never sees one.

Read operations count the same as writes. If you are polling a charge, poll it once every few seconds, not in a loop; or better, take the webhook and poll only as a fallback.

What is not limited

Unauthenticated requests — a missing or unrecognised key — are refused before anything is counted, so a flood of bad keys does not consume a real key's allowance. The sandbox's lower limit exists because nobody's checkout is waiting on a test key, and a loop in a test suite is the commonest way anyone meets this at all.