Rate limits

Each API key may make 300 requests per minute. A connected AI app has the same limit, per connection.

• The limit is shared between REST and MCP: a key that uses both has one budget.
• Each MCP tool call counts, including every call in a JSON-RPC batch.
• Minutes are fixed windows: the count resets at the start of each minute rather than rolling.
• Dry runs count; they do the same work.

Headers#

Every authenticated response tells you where you stand:

RateLimit-Limit: 300
RateLimit-Remaining: 297
RateLimit-Reset: 42

RateLimit-Reset is the number of seconds until the window resets. Over the limit, you get 429 rate_limited with Retry-After in seconds:

HTTP/1.1 429 Too Many Requests
Retry-After: 18
RateLimit-Limit: 300
RateLimit-Remaining: 0
RateLimit-Reset: 18

{"error":{"code":"rate_limited","message":"Too many requests for this API key (limit 300 per minute).","hint":"Retry after 18 seconds."}}

Responses without a valid key (401) carry no RateLimit headers. On the API host, an address whose requests fail authentication 60 times in a minute gets 429 for the rest of that minute.

Staying under it#

• Use bulk actions. org.setup.apply creates or updates up to 250 people, units and locations in one call; org.people.list returns the whole directory in one.
• Use webhooks instead of polling. A webhook tells you what changed; then fetch only that record.
• Back off on 429. Wait Retry-After seconds; don't retry in a tight loop.
• Spread scheduled jobs. A nightly sync that runs at a random minute avoids sharing a window with your other jobs.

Need more for a legitimate integration? Write to hello@bizisy.com with what you're building.