Caps and limits
Request rate, order ceilings, and the 429 contract.
Request rate
120 requests per minute, per partner. The limit is per partner account, not per credential and not per IP, so extra key pairs do not buy extra throughput.
Exceeding it returns 429:
{
"statusCode": 429,
"message": "Too Many Requests",
"error": "Too Many Requests",
"requestId": "req-1756512184903-7c1d5a0",
"retryAfterSeconds": 12
}retryAfterSeconds is also mirrored into the standard Retry-After header.
Honour the interval
A retry loop that ignores Retry-After stays refused and consumes the budget
it is waiting for. Back off for the interval given, then continue.
Polling is the usual reason integrations approach this limit. Use webhooks as the completion signal and polling as a fallback, and the limit stops being a consideration.
Order ceilings
Two ceilings apply to order creation:
- a per-order maximum, and
- a rolling 24-hour maximum across your orders.
Both are set per partner. The values are in your onboarding, not on this page — printing a number here would be wrong for most readers and would go stale for the rest.
Breaching either is a 422:
| Code | Meaning |
|---|---|
ORDER_EXCEEDS_PER_ORDER_CAP | This single order is above your per-order cap. |
ORDER_EXCEEDS_DAILY_CAP | It would breach your rolling 24-hour total. |
Neither is retryable as-is. Split the order, wait for the window to roll, or ask us to review your limits.
Minimums
There is no minimum beyond an amount greater than zero. Precision is the real constraint: KES carries at most 2 decimal places and USDT at most 6. See Money.
Payment windows
A created order must be funded within 24 hours on either leg, or it expires. The deadline is on the create response — read it rather than assuming it.