Hello Integrators,
Starting Monday, November 9, 2026 the Data Intake Gateway (DIG) will apply a rate limit to the /records endpoint. The limit keeps ingestion stable and fast for everyone by stopping any single integration from using too much capacity during a sudden traffic spike.
What's changing
- POST /records will be limited to 1,000 requests per minute.
- As with DIG's existing rate limits, the limit is counted against both your DIG user account and your source IP address. A request that goes over either one is rate limited.
- The limit counts requests, not records. A request is counted the same whether it carries one record or many.
- Rate-limited requests receive HTTP 429 TOO_MANY_REQUESTS with a Retry-After header (RFC 6585). Records in a rate-limited request are not accepted and must be sent again.
- Nothing else changes: request and response formats, the /invalidrecords endpoint, and the existing authentication limits stay the same.
Who may be affected
The limit is set well above typical integration traffic and is meant as a safeguard against sudden spikes. Integrations that batch their records are unlikely to be affected. Please review your integration if you:
- send many small requests, for example one request per device or per record, instead of batching records together
- run several DIG user accounts from the same source IP address, because these share one IP limit
- expect a big increase in device count or reporting frequency, or plan to load large amounts of historical data
What you should do
- Handle 429 responses. Wait the number of seconds given in Retry-After, then send the same request again. Don't treat a 429 as a permanent failure, and don't drop the records.
- Back off with jitter. Add a small random delay to retries so queued requests don't all retry at the same moment.
- Batch your records. We recommend 200–500 records per request on average. At 500 records per request, 1,000 requests per minute allows up to 500,000 records per minute.
- Pace large loads. Spread out historical loads and catch-up after an outage instead of sending as fast as possible.
Questions
If you have questions about this change or for any resulting production issues, please submit a support ticket through MyAdmin.
Or ask on this thread below!