Ingest API Limits and Optimizing Measurement Submissions
This topic explains the limits we impose on API calls you make to our Ingest API. Guidance is also given on:
How to manage your API calls to optimize submission of data measurements within these limits.
How to accommodate periods of service failure due, for example, to throttling or platform unavailability.
Tip: Separate from Config API Limits? Yes, the Ingest API limits are separate to the limits imposed for the Config API.
Request Rate Limits
On the Ingest API, we impose the following request rate limits:
Source IP Address. Individual host machines can send up to 5,000 requests over a rolling 5-minute period. (An average of 16 requests per second)
m3ter Organization. Each m3ter Organization can send a maximum of 50 requests per second from any number of source IP addresses.
If you exceed either of these rate limits, requests are throttled and an HTTP 429 (Too Many Requests) error response is returned:
Source IP address rate limit - 429 is returned until the total number of requests in the rolling 5-minute period drops below 5,000.
m3ter Organization rate limit - 429 is returned for the remainder of the second in which throttling has occurred.
You'll need to retry requests when throttling has finished. We recommend using an exponential back-off algorithm to manage retries - see the following Fallback and Recovery section for guidance.
Note: If you need a temporary increase in API rate limit or if you're finding that you're breaching the limit frequently, please contact m3ter Support to discuss how we can best accommodate your requirements.
Request Payload Limit
For the Ingest API, the maximum request payload size allowed is 512KB. If you exceed this request payload limit, then you'll receive a 403 (Forbidden) error response.
For more details see the Submit measurements API Reference documentation.
Batching for Higher Measurement Ingest Rate
The main technique you can use to achieve higher ingest throughput is to batch measurements. This is not aggregation of measurements - the raw data is still included in the request. The measurement Ingest API is designed to accept a batch of up to 1,000 measurements up to an overall payload size of 512KB, and we strongly recommend including as many measurements as possible in each request.
For more details see the Submit measurements API Reference documentation.
Measurement Ingest - Fallback and Recovery
The m3ter platform is designed to provide a highly available service, but it is impossible to build services that never fail. Whether a request fails through throttling or any other reason, we strongly recommend that your implementation for sending data measurements into our Ingest API is designed to be tolerant of failure.
You should back-off the raw measurement data to appropriate storage in your data architecture - for example, to disk, queue, stream service, and so on - before regularly uploading it to m3ter in batches of up to 1,000 measurements.
This approach enables easy fallback and recovery in the event you are unable to send data to m3ter due to throttling, platform unavailability, or other connection issues. Performing retries for sending the batches is easy and the data isn't lost, because it's still in your own storage. And by batching in this way, you are extremely unlikely to hit the rate limit even when recovering.
If you are already recording the data that you send to m3ter in your own metrics or logs, it should be straightforward to design this fallback approach into your process.
Additional Support
Login to the Support portal for additional help and to send questions to our Support team.