Rate limits and reliability

Rate limits

Route	Per integrator	Per IP
GET /v2/quote	120 / minute	600 / minute
POST /v2/build	60 / minute	300 / minute

Other routes are not rate limited.

• The per-IP limit is checked first, so other traffic from a shared egress IP can use up your allowance.
• Limits are counted per edge location and are approximate.
• A 429 carries no Retry-After header. Back off and retry.

Maintenance

During maintenance, /v2/quote and /v2/build return 503 with Retry-After: 300:

{ "name": "MaintenanceException", "message": "SystemMaintenance" }

The two routes pause together, so a quote never advertises an order that the next build would refuse. GET /v2/params, order reads and cancels keep working.

What an outage can affect

An API outage delays quotes, builds, order reads and settlement. It cannot change an order’s terms: the rate, the recipients and the deadline are signed when the order is built, and the contracts enforce them when it publishes and settles. A filled unit always settles at the order’s rate.

If the API is unavailable when an order’s deadline passes, settlement normally runs once service resumes. Meanwhile the funds stay in the hub contract under the order’s signed terms. If an order has not settled after service is back, contact Khalani with the orderId.

Readiness and health

• GET /v2/params is your readiness check. It reflects your account and keeps working during maintenance.
• GET /v2/health reports the order pipeline across all integrators. It returns 200 with status: "ok", or 503 with status: "degraded" when the order store cannot be read. Use it for monitoring, not for logic.

Getting help

Contact Khalani through your onboarding channel. Include the orderId if there is one, the x-request-id of the response, and the time of the call. Contact Khalani in particular when:

• an order stays at deposited, or
• an order reaches delivery_failed.