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

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 check 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. These default limits can be increased upon request. Reach out to your customer success manager for more information.

Batching API requests

Braze 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 event objects, 75 attribute objects, and 75 purchase objects. Each object (event, attribute, and purchase arrays) can update one user each. In total, this means a maximum of 225 users can be updated in a single call. In addition, a single user profile can be updated by multiple objects.

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
• Users who match additional audience filters of any size, defined in the request as a connected audience object

Example batch request

The following example uses external_id to make one API call for email and SMS.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
curl --location --request POST 'https://rest.iad-01.braze.com/v2/subscription/status/set' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR-REST-API-KEY' \
--data-raw '{
  "subscription_groups":[
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    },
    {
      "subscription_group_id":"subscription_group_identifier",
      "subscription_state":"subscribed",
      "external_ids":["example-user","[email protected]"]
    }
  ]
}

Monitoring your rate limits

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

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 make sure 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 through our /user/alias/new endpoint, and then hitting that alias to send a custom event through 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, so we recommend that you allow for a 5-minute delay between making subsequent calls to minimize the probability of error.