Developer docs
Rate limits
Limits count per account, for every key and connected app on it together. Each limit counts in fixed windows on the clock (UTC): every minute, ten minutes, hour or day, as the table says, starts a new count, so calls just before and just after a window starts count separately.
| What | Limit |
|---|---|
| Calls | 120 a minute |
| Changes (calls that need read and write access) | 30 a minute, within the calls |
| Adding webhook endpoints, and changing their address | 10 an hour |
| Test events | 30 an hour |
Re-checks of one transfer (recheck_transfer) | 1 a minute and 20 a day |
| Re-checks across the account | 20 a minute and 500 a day |
| Calls with a well-formed key or token that is not valid, per network address | 20 in 10 minutes |
The re-check limits count every re-check of the account's transfers, from the website, a timeline link or the API, and scheduled checks never count. A transfer is never re-checked twice at once: a re-check while another of the same transfer runs, or over its limit a minute, is refused with recheck_cooldown. The other re-check limits refuse with rate_limited.
A call over a limit is refused with HTTP 429 and the code rate_limited. The answer has a Retry-After header and retry_after_seconds in the body: wait at least that long, then try again. When many calls are refused, back off further each time and add a little random delay, so several workers do not retry together.
Your plan also limits how many transfers are active at once, as on the website. An add over that limit is refused with active_transfer_limit, which says how many transfers to archive.
A custom package limits the transfers added in each billing period instead. An add over that limit is refused with monthly_limit_reached, whose resets_at and Retry-After say when new transfers can be added again.
When very many transfers are added across all accounts at once, a new transfer's first bank check can wait for the next regular check. The add itself always succeeds.