Rate limits

Who this is for

Integration engineers designing batch jobs, polling and retry logic, and architects assessing capacity planning for a bank integration.

Documented limits

The API Reference documents the following limits in the platform itself.

Limit	Applies to	Value	When exceeded
Webhook replay budget	`POST /api/webhook-events/{id}/redeliver` and `POST /api/webhook-events/redeliver`, per organisation	At most 1,000 replays per hour	`429 Too Many Requests`. Nothing is queued by the refused call.
Filtered replay size	`POST /api/webhook-events/redeliver`, per call	Queues at most 500 events and examines at most 2,000	Not an error. The response carries `truncated: true`; call again to continue.
Page size	List endpoints	See Pagination and filtering. Most cap at 100.	`400`, or the value is reduced to the maximum, depending on the endpoint.

General request rate limits

General request rate limiting is applied at the edge, in front of the platform's services, together with request allowlisting and web application firewall rules. Who sets the limits depends on who hosts the deployment:

Deployment	Where rate limits are applied	Who sets them
Hosted by Quant Network	Quant Network's edge gateway	Quant Network
Hosted by your bank	Your bank's own edge, under your own DDoS and abuse-management arrangements	Your bank

The platform's services do not apply their own per-client request quotas today.

Obtain the per-environment request budgets and any increase process from your platform contact. Do not infer production capacity from sandbox throughput or an endpoint with no documented limit.

Handle 429 from the gateway as well as documented service limits. Honour Retry-After when returned; do not require remaining-quota headers that the public contract does not guarantee.

Retry-After

The Retry-After header appears on two documented responses. Both concern an idempotency key that is still being processed:

409 Conflict on POST /api/customers and POST /api/accounts, when an earlier request under the same Idempotency-Key is still running.
409 Conflict on PATCH /api/customers/{customerRef} and PATCH /api/accounts/{accountRef}, for the same reason.

The value is in seconds. Wait that long, then resend with the same key.

The replay budget 429 does not document a Retry-After header. Its message states the budget and window. Retry later, or reduce the scope of the replay.

Designing within the limits

Prefer webhooks to polling for operation outcomes. See Webhooks.
Batch replays by filter after an outage, using status=PARKED and a time window, instead of replaying event by event.
Back off on 5xx with increasing delays, and cap the number of attempts. Use exponential backoff with jitter and a bounded attempt budget chosen for your integration. Apply one retry policy per operation class and preserve idempotency keys on writes.
Honour Retry-After whenever it is present.

Worked example

A filtered replay after the organisation has used its hourly budget:

POST /api/webhook-events/redeliver HTTP/1.1
Host: api.qfp.quantnetwork.net
Authorization: Bearer eyJraWQiOiJ...
API-Version: 1.0.0
Content-Type: application/json
Idempotency-Key: 2e7c9a10-4d3b-4f86-b5a2-91c0e8d4f372

{
  "status": "PARKED"
}

HTTP/1.1 429 Too Many Requests
Content-Type: application/json

{
  "timestamp": "2026-08-28 14:07:41.552",
  "status": 429,
  "error": "Too Many Requests",
  "message": "Replay budget exhausted: at most 1000 deliveries may be replayed per PT1H. Try again later."
}

View in API Reference

Queue every settled delivery a filter selects to be delivered again · POST

Errors and edge cases

A truncated replay is not a failure. truncated: true with a 202 means some matches were queued and more remain.
The budget counts queued replays. One call can queue many. A filtered replay that queues many deliveries uses more of the budget than one that queues few.
Different page size rules. Some list endpoints reject an oversized size with 400; others reduce it silently. Read the page size returned in the response.

API Reference

Open an endpoint for request fields, response examples and the interactive API console.

Operation	Method
Queue every settled delivery a filter selects to be delivered again	`POST`
Queue one event to be delivered again	`POST`
Register a customer	`POST`
Register an account	`POST`