The two limits
200 requests per minute, per key, across every endpoint together. Two keys have two separate budgets; two processes sharing one key share one budget.
20 requests per minute, per key, on
/v1/bank_detailsspecifically. This one stacks on top of the first rather than replacing it, so the stricter of the two is what binds.
At the maximum page size the tighter limit is still several thousand accounts a minute, which is well above a full sync. It is a bound on bulk extraction, not a throttle a normal integration will feel.
What a 429 looks like
It is the one exception to the error envelope described in Partner API: errors and the message_key contract. A 429 is produced by the rate limiter before your request reaches the API at all, so it carries no JSON body of ours.
Do not parse a 429 body. There is no error.code and no error.message_key in it. Key off the HTTP status alone.
There is also no Retry-After header today. Do not write code that waits for one; it will wait forever.
What to do instead
Back off a fixed interval — waiting 60 seconds and retrying is the whole strategy, because both limits are per minute.
Cap your concurrency rather than firing requests as fast as they return. One request at a time, paging through with
cursor, comfortably fits inside both limits.Pull reference data on a schedule, not per record. Departments and designations change a few times a year; fetching them once per employee is the most common way an integration hits the limit.
If your integration genuinely needs a sustained higher rate, talk to your Asanify contact before you build around aggressive polling.