/api/send are rate limited per API key. The key is the
bearer token in Authorization: Bearer <api_key>, the same credential
described in
Credentials.
Each API key has its own counters. Every caller that sends that key,
including calls from different servers, shares those counters.
Each limit below is a 5-minute (300 second) window. A request
counts toward exactly one limit.
Limits
These three resend operations share a single limit of 30 requests per
5 minutes:
POST /api/send/bank_accounts/{id}/resend_webhook_eventPOST /api/send/send_instructions/{id}/resend_webhook_eventPOST /api/send/send_limits/{id}/resend_approval_requests
POST on those exact paths.
GET, DELETE, PATCH, and any other write under /api/send use
the general limit of 300. That includes listing or retrieving a send
instruction, bank account, or send limit, deleting one, and
POST /api/send/groups. Exhausting one limit leaves the others
available: a 429 from POST /api/send/bank_accounts leaves
DELETE /api/send/bank_accounts/{id} and
POST /api/send/send_instructions on their own limits.
A single trailing format suffix is removed before the limit is chosen,
and the suffixed call shares the counter with the path without the
suffix. POST /api/send/send_instructions.json and
POST /api/send/send_instructions.JSON both use the 100-request limit
together with POST /api/send/send_instructions. The same applies to
a suffix such as .json on the bank-account, send-limit, and resend
paths.
These limits apply to /api/send and paths under /api/send/.
Webhook management is served at /api/webhooks, which is outside
this limit.
When you exceed a limit
CHIP responds with429 Too Many Requests and a JSON body in the same
shape as other CHIP Send errors (message, code, and data):
data.retry_after is the window length in seconds. For these limits
it is 300.
The 429 also includes the headers below.
Retry-After, X-RateLimit-Limit, X-RateLimit-Remaining, and
X-RateLimit-Reset are sent on the 429. Other responses omit them.X-RateLimit-Limit is the limit for the request that was rejected:
100, 60, 30, or 300. Retry-After and data.retry_after
stay 300. X-RateLimit-Reset is the Unix time of the response plus
300 seconds.
This example is POST /api/send/send_instructions after its
100-request limit, generated at Unix time 1792984200
(2026-10-26 03:10:00 UTC). X-RateLimit-Reset is 1792984200 + 300.
Back off and retry
Wait at leastRetry-After seconds before you send the request again.
data.retry_after is that same delay. Avoid a tight retry loop: once
the window is open again, immediate repeats will spend the new
allowance at once.
Spread bulk work across the 5-minute window. The tightest limits are
creating send instructions (100), creating bank accounts or send
limits (60 each), and resends (30, shared by all three resend
operations). A short burst can use an entire limit. Further calls on
that limit then receive 429 until Retry-After seconds have passed.
A steady pace that stays inside each limit is about one send
instruction every 3 seconds, one bank-account or send-limit create
every 5 seconds, and one resend every 10 seconds across the shared
resend limit. Other /api/send calls can run at about one per second.