Limits and Performance
Design integrations around bounded requests. A request that retrieves only the needed records and fields is easier to retry and less likely to time out.
Data API limits
| Control | Current behavior |
|---|---|
Read limit | Required; between 1 and 10,000 records |
Read skip | Optional; defaults to 0 |
| Insert request size | 1 to 1,000 records per POST /api/v1/data/{provider}/{dataset}/ request |
| Request timeout | Keep individual requests comfortably below the platform timeout by paging results |
The values documented here are verified against the current data-api request validation. Use the maintained Data API Reference for request parameters and examples.
Performance checklist
- Filter by
asset_id,company_id, time, or another indexed field. - Select only fields the consumer uses.
- Request a small
limitwhile developing. - Sort on fields supported by dataset indexes.
- Page through large exports and checkpoint progress.
- Set a client-side timeout.
- Retry transient failures with exponential backoff and jitter.
- Do not retry authentication, authorization, or validation errors without changing the request.
Error handling
| Status | Action |
|---|---|
400 Bad Request | Correct malformed JSON or unsupported parameters. |
401 Unauthorized | Check the Authorization header, API key status, and Bearer expiry. |
403 Forbidden | Request access or choose a resource available to the key. |
404 Not Found | Verify the endpoint, provider, dataset, and asset identifiers. |
422 Unprocessable Entity | Correct a missing or out-of-range parameter. |
429 Too Many Requests | Back off before retrying. |
5xx | Retry a bounded number of times; preserve diagnostics if failures continue. |
Always log the endpoint, response status, elapsed time, and non-sensitive error details. Never log API keys, Bearer tokens, refresh tokens, or passwords.