ZYKAY is in beta. Learn more about our privacy-first age verification.

Rate-Limit Policy

Reference of published limits and recommended behavior on the partner side.

Endpoints with explicit limits

EndpointLimitWindowLimitation keyResponse 429
GET /api/w/verify-status/:requestId?pt=...30 requests60srequest_idRATE_LIMITED + Retry-After: 60
POST /api/partner/verify-request60 requests60sClient IP{"error":"Too many requests"}
GET /api/partner/verify-status/:requestId60 requests60sClient IP{"error":"Too many requests"}
POST /api/billing/session (pre-auth)30 requests60sClient IP{"error":"Too many requests"}
POST /api/billing/session (post-auth)100 requests60sPartner ID{"error":"Too many requests"}

Endpoints Partner API (api.zykay.com)

For POST /v1/exchange and POST /v1/introspect, there is no fixed public quota in this reference version.

To be on the safe side, your backend should:

  1. treat any 429 response as transient
  2. apply a bounded exponential backoff
  3. maintain caller side idempotence

Recommended retry strategy

  1. If header Retry-After present, respect it as a priority
  2. Otherwise, use exponential backoff with jitter (max 30s)
  3. Limit to 3 attempts before user failure

Example:

tentative 1: 1s (+ jitter)
tentative 2: 2s (+ jitter)
tentative 3: 4s (+ jitter)

Best practices

  • Do not poll faster than necessary (avoid an interval less than 1s on the client side).
  • Immediately stop retries on 401/403/400 errors (non-transient).
  • Log X-ZK-CID for correlation support.
Quick Start