Rate Limits / Request Limits

Bringg API Call Limits / Thresholds / Restrictions / RPS Capacity Management


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
Every HTTP request to Bringg should respond with IETF-standard RateLimit-related headers

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.

Scope of Rate Limits

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_user requests trigger the rate limit, this will cause create_task requests 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.

Best Practices - Handling Rate Limit Warnings and Errors


Stay Informed

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 HeaderDescription
RateLimit-LimitContains 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 RateLimit-Reset.
RateLimit-RemainingContains 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 RateLimit-Remaining value is a guarantee of being served. A low RateLimit-Remaining value is like a yellow traffic-light: the red light may arrive suddenly.
RateLimit-ResetIndicates the number of seconds remaining in the current window at which point the quota resets.

The behavior of RateLimit-Reset is compatible with the delta-seconds notation of Retry-After.

The RateLimit-Reset value should not be considered fixed nor constant; and it would be unwise to assume that the full or the previous request-quota value will be restored immediately after the moment referenced by RateLimit-Reset. Other factors - including persistent throttling, resource saturation or due to sliding window policies - may cause the server to arbitrarily alter the RateLimit-Reset value between subsequent requests.

To allow for network latency, it may also be advisable to wait an additional moment after the RateLimit-Reset before probing the server again.

Best Practices - Avoiding Rate Limit Errors

  1. Proactively monitor your request levels to avoid triggering the rate limits.

  2. Use caching responses where possible to avoid the need to frequently make the same request.

  3. Use Webhooks instead of polling for tracking or notifying on changes.

  4. 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.

  5. 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.

  6. 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.

Requesting Changes in Rate Limits / Whitelisting IP Addresses

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.