ZyloPaydocs

Rate limits

Per-key limits per minute, separate for reads and writes, reported in RateLimit headers.

Each API key has two budgets per one-minute window: one for reads (GET) and one for writes (everything else).

ModeReads per minuteWrites per minute
Live (zp_live_…)1500300
Test (zp_test_…)600120

Every response reports the budget of its kind:

RateLimit-Limit: 1500
RateLimit-Remaining: 1487
RateLimit-Reset: 42
RateLimit-Policy: 1500;w=60;comment="reads per API key"
HeaderMeaning
RateLimit-LimitRequests allowed in the current window.
RateLimit-RemainingRequests left in the window.
RateLimit-ResetSeconds until the window resets.
RateLimit-PolicyThe limit and the window length in seconds.

Over the limit, the API answers 429 with type: "rate_limit_error" and a Retry-After header (seconds). Wait that long, then retry.

Staying under the limits

  • Use webhooks instead of polling. A webhook costs you nothing against the limit.
  • Page with limit=100 for bulk reads.
  • Back off exponentially with jitter on 429 and 5xx. The Node SDK does this and honours Retry-After.
  • Spread batch jobs. A reconciliation job that walks a day of payments uses a few requests per thousand payments.

Precision

Limits are counted per API server. ZyloPay runs more than one, so in rare cases a burst can pass slightly above the stated limit before it is refused. Do not rely on that headroom. A separate, higher per-IP ceiling protects the service as a whole.

Need higher limits? Contact support.

Pagination

Lists are newest first and paged with a cursor. Never with an offset.

Versioning and changes

/v1 in the path, dated versions within it, and what ZyloPay may change without a new version.

On this page

Staying under the limitsPrecision