Rate Limits define the maximum number of requests that can be made to the Bringg API over a given period of time. Bringg actively monitors and enforces rate limits to ensure availability and stability of our API services for all customers and partners, and to prevent any abuse or inappropriate usage.
Overview of Bringg Rate Limits
Clients and integration partners are encouraged to familiarize themselves with these IETF-standard headers and to make the required adaptations to stay within the applicable limits to avoid their requests being throttled.
Full details of the IETF-specifications are available at: https://tools.ietf.org/id/draft-polli-ratelimit-headers-02.html.
To prevent abuse and to handle API request traffic efficiently, we may alter any stated limits if required.
Bringg applies a number of different API thresholds, limits and restrictions. The methods and best practices included in this guide are applicable to all limits, but for security reasons, only a selection of the thresholds are documented in the guidelines below.
Default API rate limits are applied to all users and customers unless otherwise stated or by prior agreement. For details of the current rate limits, please speak to your Bringg representative.
Increases in rate limits will be considered on a per-case and per-customer basis, based on demonstrated and projected usage. See Requesting Changes in Rate Limits below.
Merchant Rate Limits apply equally to all request types from any single merchant regardless of the request type or API endpoint. For example, if excessive
create_userrequests trigger the rate limit, this will cause
create_taskrequests to be throttled as well.
Merchant-IP Rate Limits apply per merchant, per IP address.
Global-IP Rate Limits apply to all requests from an IP address, regardless of the originating merchant.
Bringg API rate limits are usually sliding-window-based e.g. if a rate limit is max 2800 requests over a period of 5 minutes, that will apply to any given 5-minute period.
Register as a Developer at support.bringg.com or sign up for the Bringg Weekly Product Update emails to receive release notes and updates.
When you exceed the rate limits allowed for an API request, you will receive a
429 Too Many Requests error response. The best way to handle rate limits is to be on the lookout for
429 status codes and build in a retry mechanism that makes reduced number of requests to the server in a given timeframe.
For time-rated limits, a
RateLimit-Reset header will be included to the response indicating how long you must wait before making the next request. The behavior of the
RateLimit-Reset value is compatible with the
delta-seconds notation of the
Retry-After defined in RFC7231.
X-Ratelimit-Limit: 2800 X-Ratelimit-Remaining: 2780 X-Ratelimit-Reset: 1606175096
The table below lists Response Headers you might encounter and values you might see when you approach or reach the rate limits:
HTTP Response Header
Contains an integer value equal to the maximum number of requests that the server is willing to accept from one or more clients under a given policy (e.g. originating IP, authenticated user, geographical etc - as described above) during any given time-window.
Time-window duration can differ by rate limit type. The remaining duration of the current window is the delta-seconds value sent via
Contains the remaining requests quota in the current time window.
Requests that exceed this limit MAY not be served.
It should not be assumed that a positive
Indicates the number of seconds remaining in the current window at which point the quota resets.
The behavior of
To allow for network latency, it may also be advisable to wait an additional moment after the
Proactively monitor your request levels to avoid triggering the rate limits.
Use caching responses where possible to avoid the need to frequently make the same request.
Use Webhooks instead of polling for tracking or notifying on changes.
Distribute your traffic as widely as possible across multiple IP addresses. Corporate proxy servers are a common cause of rate limit issues where high volumes of traffic, from different internal origins and different request types, share a small IP range or single IP address.
Where possible, your QA endpoints for APIs should not share the same IP address as your Production endpoints. Bringg’s automated throttling mechanisms apply to all traffic originating from the same IP address. QA-type automation, load-tests and other testing are common causes of unexpected spikes in API requests.
In some cases, web-based Dispatcher App communications and even Driver App communications (where the driver is connected via corporate Wi-Fi) can also contribute against your rate limit. This can be avoided by ensuring:
Outgoing traffic does not share the same IP address
Reliable websocket-connectivity will prevent API-based updates to Dispatchers. The API is used where websockets are not stable.
Drivers connecting to in-store-type WiFi do not have their traffic routed via a centralized IP address.
Bringg will review requests for increases in rate limits, and in limited cases, whitelisting IP addresses.
Permanent increases in rate limits will only be considered for merchants who have:
Made a request via their Bringg Customer Success Manager.
Implemented appropriate measures to avoid high-risk integrations e.g. prevention of sudden or unexpected scaling; managing third party submissions; blocking of poorly formed data;
Implemented effective request-control / throttle-response mechanisms
Provided Emergency Contacts and Development Contacts who can liaise with Bringg's Support Team as required
Please note that white listing IP addresses is only available for static and wholly-dedicated IP addresses and ranges.
Updated 7 months ago