API Rate Limiting is a control that caps how many requests a client can send to an API in a set window, for example 100 requests per second per API key, and rejects or delays anything above the cap. The server identifies the caller by API key, OAuth client ID or IP address and counts requests with a fixed or sliding window or a token bucket; excess calls receive HTTP 429 "Too Many Requests", often with a Retry-After header. Payment providers, banks and data platforms use it to prevent overload, credential stuffing and scraping. Open banking adds a regulatory cap on background AISP refreshes. Clients that ignore limits risk failed batches and duplicate payouts.
How does API rate limiting work
The server identifies the caller, usually by API key, OAuth client ID or IP address, and counts its requests. The two most common algorithms are the fixed or sliding window, which counts calls in each second or minute, and the token bucket, where each client has a bucket that refills at a steady rate and every request takes one token. A token bucket refilling at 50 tokens per second with a capacity of 200 allows a short burst of 200 calls, then settles at 50 per second.
When a client exceeds its limit, the API returns HTTP status 429 "Too Many Requests", often with a Retry-After header saying how many seconds to wait. Well-designed APIs also return headers showing the limit, the remaining calls and the reset time, so clients can slow down before they are blocked.
Rate limit vs throttling
Rate limiting rejects excess requests. Throttling slows them down, queuing or delaying calls rather than refusing them. Many platforms combine the two: soft throttling as a client approaches its limit, hard rejection with 429 beyond it. Limits are commonly tiered, with different caps for read endpoints, payment creation and bulk reporting.
Open banking rate limits
In the EU and UK, there is a regulatory rate limit on top of technical ones. Under the PSD2 Regulatory Technical Standards, an AISP may access a customer's account data without the customer actively requesting it no more than four times in a 24-hour period, unless the bank and the AISP agree a higher frequency with the customer's consent. Banks enforce this cap in their open banking interfaces and reject the fifth background refresh.
Example: why client-side handling matters
An illustrative marketplace runs payouts through a provider allowing 25 payout requests per second. At month-end it needs 30,000 payouts. Sent all at once, most fail with 429 and some get retried with a new reference, creating duplicates. Sent at 20 per second with exponential backoff on 429 and an idempotency key on every call, the batch finishes in 25 minutes with no duplicates.
Rate limiting also limits damage when credentials leak: a stolen key restricted to 10 calls per second cannot extract a full customer database in minutes.
For a buyer of a payments or banking-as-a-service platform, rate-limit configuration and 429 logs show whether the infrastructure has headroom for growth, and whether any large client is close to its contractual cap.