Rate limits

There is no requests-per-second limit. What is limited is how much work you can have queued at once.

100 pending bulk requests

A profile may have 100 bulk requests in flight at any moment. Submit a 101st while 100 are still pending and it is rejected:

{
  "message": "You can only have up to '100' pending bulk requests at any given.",
  "errorCode": "integration/too-many-pending-requests"
}

with status 429.

The count is of requests that have not yet reached a terminal state, per profile — not per API key, so several keys belonging to the same profile share the allowance. Requests drop out of the count as they finish.

What to do about it

Backing off on a timer is the wrong response here, because the limit is not about how fast you are sending — it is about how much is outstanding. Waiting a fixed interval and retrying will keep failing if your queue is genuinely full.

Poll the requests you already submitted, let them reach a terminal state, and submit more as capacity frees up. If you are consistently hitting the ceiling, you are almost certainly splitting your work too finely: fewer, larger requests move the same data using far less of the allowance.

Synchronous endpoints

The reference-data endpoints — Groups, Frameworks, Unit Types and the custom identifier lookup — are not queued and do not count toward the limit. They are not separately throttled, but they are also not intended to be polled in a loop; fetch what you need to build a request, not on every iteration of one.