Rate Limiting

The Partner API applies per-minute and per-day request limits so that one integration cannot degrade the service for everyone else. The limits are generous for typical partner integration patterns (creating and reading patients, placing orders, checking invoices, and receiving webhooks). You will normally only encounter them if you poll an endpoint on a tight interval or run a large bulk operation.

How limits are scoped

Limits are counted per practitioner credential, not pooled across your whole partner account. Each practitioner (client token) you authenticate as has its own independent allowance, so a single busy practitioner never uses up another's capacity.

A small number of endpoints authenticate with your partner token alone, without a practitioner context. Those requests are counted per partner account.

Limits

For requests authenticated with a partner token and a practitioner (client) token:

Endpoint	Limit
Create an order (POST /orders)	30 per minute
Read results (GET /tests)	120 per minute
Read the catalogue (GET /products)	30 per minute
All other endpoints	60 per minute
Across all endpoints	5,000 per day

For requests authenticated with the partner token alone:

Scope	Limit
All endpoints	60 per minute
Across all endpoints	5,000 per day

When you exceed a limit

A request over the limit receives a 429 Too Many Requests response with a Retry-After header giving the number of seconds to wait before retrying. Wait at least that long before sending the request again.

Every response, including 429, carries an X-Request-Id header. Quote this value if you contact us about a specific request, as it lets us trace it in our logs.

Best practices

• Prefer webhooks over polling where an event exists for what you need (see Webhooks). Polling GET /patients or GET /tests on a fixed interval to detect changes creates unnecessary load compared to reacting to resultsReady, formReady, orderReady, invoiceSettled, or patientLinkRequestApproved.
• Use pagination. Endpoints that return collections (GET /patients, GET /patients/link-requests) accept skip/limit; request pages rather than trying to retrieve everything in one call.
• Cache practitioner and product data. Practitioner details and product catalogues change infrequently. Re-fetching them on every patient action is rarely necessary and is the most common way to hit the catalogue limit.
• Back off on errors. On a 429 Too Many Requests, honour the Retry-After header rather than retrying immediately in a loop. For 5xx responses, an exponential backoff (for example, 1s, 2s, 4s, up to a small maximum) is standard practice.

If you're building a new integration or planning a significant increase in call volume, reach out first at the same contact used for webhook URLs so we can confirm the pattern will scale comfortably and adjust your limits if needed.