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.

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:

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.