Rate Limits / Request Limits

📘
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 Delivery Hub 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.

Overview of Bringg Rate Limits

Every HTTP request to Bringg Delivery Hub 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.
Account Rate Limits apply equally to all request types from any single account regardless of the request type or API endpoint.
Account-IP Rate Limits apply per account, per IP address.
Global-IP Rate Limits apply to all requests from an IP address, regardless of the originating account.
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

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	Description
RateLimit-Limit	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 `RateLimit-Reset`.
RateLimit-Remaining	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 `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-Reset	Indicates 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

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.

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