Limits are applied per API key. General requests, batch submissions, and experimental sandbox estimates use separate controls so asynchronous or research workloads do not consume the entire general request bucket.
| Workload | Default limit | Notes |
|---|---|---|
| Sandbox general requests | 60 per key/minute | Applies to normal synchronous API traffic. |
| Production general requests | 300 per key/minute | Effective values are configuration-backed. |
| Batch submissions | 10 per key/minute | Separate from the general bucket. Polling remains normal API traffic. |
| Provider return jobs | 5,000 items per job | Each client/state period is isolated. Submission and polling use the provider key's normal request buckets. |
| Experimental sandbox estimates | 5 per key/minute | Also limited to four concurrent calls per application process. |
Batch workload controls
- One calculation batch contains at most 500 independently isolated items.
- One provider return job contains at most 5,000 independently isolated client/state periods.
- Completed and failed batch payloads are retained for 30 days.
- Use a unique
reference_idfor each item and poll the returned batch ID.
Discover effective values
Call GET /api/v1/config with the same key used by the integration. The response publishes the effective general request limit and window for that environment. Use GET /api/v1/operations/status for tenant-scoped request, batch, and webhook queue signals.
Handle 429 responses
A throttled request returns 429 rate_limit_exceeded and a Retry-After header. Wait at least that interval, add jitter when several workers share a key, and bound retries. Do not assume undocumented rate-limit headers are present.
- Stateless calculations are safe to retry.
- Send a stable
Idempotency-Keywhen retrying transaction writes. - Do not submit a replacement batch simply because polling is still pending.
- Use separate keys for independent applications when operational ownership and scope require it—not to evade limits.
Error-envelope details are documented on Errors. Provider portfolio batching and retry behavior are documented in the service-provider guide.