Rate Limits & Quotas

This page covers the limits that affect how you size and pace your imports, and how to keep your integration reliable under load.

Payload size

Keep each request under 8 MB. The platform accepts larger bodies — up to a hard limit of 100 MB, beyond which it returns 413 Payload Too Large — but smaller requests are markedly more reliable: quicker to transmit, far less likely to hit a gateway timeout, and easy to retry. Because most endpoints accept a JSON array, you control how much each call carries; there’s no need to send one record per request.

Choosing a batch size

There’s no single right number; it depends on how big each record is and how your source data is organised. A practical approach:

Keep each request comfortably under the 8 MB recommended size.
Group related records (for example, a parent asset and its children) into the same batch so references resolve within one job.
Split very large datasets into batches you can re-submit independently if one job partially fails — see Job Status & Polling.

Request throttling

Per-tenant request-rate and concurrency limits aren’t published yet, so don’t hard-code assumed numbers. As a client, build for throttling regardless of the exact numbers:

Treat 429 (and 503) as retryable. Back off and try again rather than failing hard.
Use exponential backoff with jitter between retries. Honour a Retry-After header if one is present.
Cap concurrency: submit a bounded number of imports in parallel rather than firing everything at once.
Keep polling intervals reasonable; tight polling is itself a source of load.

Job processing

Submitting an import is fast, but processing happens on a background worker and takes time proportional to the job size. Two consequences:

A 202 Accepted means queued, not done. Always poll the job for the real outcome.
Very large jobs take longer to reach a terminal state, so back off your polling accordingly.