Rate limits
Limits are set per account against your expected volume.
Rate limits are applied per account and agreed during onboarding against the volume and peak rate you tell us to expect. If you are planning a launch spike or a campaign, tell your account manager in advance rather than discovering the ceiling in production.
When you exceed a limit#
At launch there is no dedicated rate-limit status code and no Retry-After header. When the gateway needs to shed load it returns 503 Service Unavailable, the same code it returns when it is briefly busy for any other reason. So a 503 means back off, whatever its cause, and you cannot infer a specific wait time from the response.
Treat every 503 the same way. You cannot tell a load-shedding 503 from a transient one, so handle both identically: wait, then retry the same request with the same idempotency key. Because create calls are idempotent, retrying is safe.
Backoff without a Retry-After#
With no header to tell you how long to wait, use exponential backoff with jitter: wait a short base interval, and roughly double it on each further 503 or 5xx, up to a sensible cap, adding a small random offset so retries from many workers do not land together.
Staying inside the limits#
- Rely on webhooks for outcomes rather than polling every transaction on a short interval.
- If you must poll, poll transactions that are still non-final, and widen the interval as a transaction ages.
- Use exponential backoff with jitter on rejected requests and on 5xx responses.
- Batch your reconciliation reads using the list endpoints rather than fetching transactions one at a time.
Maly Tech Ltd. This guide is provided for information. Where it differs from your signed agreement, the agreement applies.