Skip to content

API rate limits

The Braze API infrastructure is designed to handle high volumes of data across our customer base. To this end, we enforce API rate limits per app group. A rate limit is the number of requests the API can receive in a given time period. Many load-based denial-of-service incidents in large systems are unintentional—caused by errors in software or configurations—not malicious attacks. Rate limits ensure that such errors don’t deprive our customers of Braze API resources. If too many requests are sent in a given time frame, you may see error responses with a status code of 429, which indicates the rate limit has been hit.

Rate limits by request type

The following table lists the default API rate limits for different request types. All other requests not listed in this table have a default rate limit of 250,000 requests per hour.

These default limits can be increased upon request. Reach out to your customer success manager for more information.

Request Type Default API Rate Limit
/users/track Requests: 50,000 requests per minute.

Batching: 75 events, 75 purchases, and 75 attributes per API request. See Batching User Track requests for more.
/users/export/ids 2,500 requests per minute.
20,000 requests per minute, shared between the endpoints.
/users/external_id/rename 1,000 requests per minute.
/users/external_id/remove 1,000 requests per minute.
/events/list 1,000 requests per hour, shared with the /purchases/product_list endpoint.
/purchases/product_list 1,000 requests per hour, shared with the /events/list endpoint.
/messages/send 250 requests per minute when specifying a segment or Connected Audience. Otherwise, 250,000 requests per hour.
/campaigns/trigger/send 250 requests per minute when specifying a segment or Connected Audience. Otherwise, 250,000 requests per hour.
/canvas/trigger/send 250 requests per minute when specifying a segment or Connected Audience. Otherwise, 250,000 requests per hour.
/sends/id/create 100 requests per day.
/subscription/status/set 5,000 requests per minute.
1,000 requests per minute, per app group.
10 requests per minute, per app group.
5 requests per minute shared between the endpoints.
100 requests per minute shared between the endpoints.
50 requests per minute shared between the endpoints.
GET: /scim/v2/Users/YOUR_ID_HERE
GET: /scim/v2/Users?filter=userName eq “[email protected]
PUT: /scim/v2/Users/YOUR_ID_HERE
DELETE: /scim/v2/Users/YOUR_ID_HERE
POST: /scim/v2/Users/
5,000 requests per day, per company, shared between the endpoints.

Batching API requests

Braze’s APIs are built to support batching. With batching, Braze can take in as much data as possible in a single API call so that you don’t need to make a lot of API calls. It’s more efficient for Braze to process data in batches than to process data one call at a time. For example, handling 1,000 batched API calls requires less resources than handling 75,000 individual calls. Batching is extremely important for any application that may require more than 75,000 calls per hour.

Batching User Track requests

Each /users/track request can contain up to 75 events, 75 attribute updates, and 75 purchases. Each component (event, attribute, and purchase arrays), can update up to 75 users each (max of 225 individual users). Each update can also belong to the same user for a maximum of 225 updates to a single user in a request.

Requests made to this endpoint will generally begin processing in this order:

  1. Attributes
  2. Events
  3. Purchases

Batching Messaging endpoint requests

A single request to the Messaging endpoints can reach any one of the following:

  • Up to 50 specific external_ids, each with individual message parameters
  • A segment of any size created in the Braze dashboard, specified by its segment_id
  • An ad-hoc audience segment of any size, defined in the request as a Connected Audience object

Monitoring your rate limits

Every single API request sent to Braze returns the following information in the response headers:

Header Name Description
X-RateLimit-Limit The maximum number of requests that you can make in a specified interval (your rate limit).
X-RateLimit-Remaining The number of requests remaining in the current rate limit window.
X-RateLimit-Reset The time at which the current rate limit window resets in UTC epoch seconds.

This information is intentionally included in the header of the response to the API request rather than the Braze dashboard. This allows your system to better react in real time as you’re interacting with our API. For example, if the X-RateLimit-Remaining value drops below a certain threshold, you might want to slow sending to ensure all transactional emails go out. Or, if it reaches zero, you might want to pause all sending until the time specified in X-RateLimit-Reset elapses.

If you have questions about API limits, contact your customer success manager or open a support ticket.

Optimal delay between endpoints

Understanding the optimal delay between endpoints is crucial when making consecutive calls to the Braze API. Problems arise when endpoints depend on the successful processing of other endpoints, and if called too soon, could raise errors. For example, if you’re assigning users an alias via our /user/alias/new endpoint, and then hitting that alias to send a custom event via our /users/track endpoint, how long should you wait?

Under normal conditions, the time for our data eventual consistency to occur is 10–100ms (1/10 of a second). However, there can be some cases where it takes longer for that consistency to occur. Therefore, we recommend that you allow for a five-minute delay between making subsequent calls to multiple endpoints to minimize the probability of error. This recommendation does not apply to consecutive endpoint calls to the same endpoint.

New Stuff!