Skip to content

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.

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.
/users/delete
/users/alias/new
/users/alias/update
/users/identify
/users/merge
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.
/campaigns/data_series 50,000 requests per minute.
/messages/send 250 requests per minute for broadcast calls (when only specifying a segment or Connected Audience). Otherwise, 250,000 requests per hour.
/campaigns/trigger/send 250 requests per minute for broadcast calls (when only specifying a segment or Connected Audience). Otherwise, 250,000 requests per hour.
/canvas/trigger/send 250 requests per minute for broadcast calls (when only 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.
/preference_center/v1/{preferenceCenterExternalId}/url/{userId}
/preference_center/v1/list
/preference_center/v1/{preferenceCenterExternalId}
1,000 requests per minute, per workspace.
/preference_center/v1
/preference_center/v1/{preferenceCenterExternalId}
10 requests per minute, per workspace.
/catalogs/{catalog_name}
/catalogs
/catalogs
50 requests per minute shared between the endpoints.
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items
16,000 requests per minute shared between the endpoints.
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items
/catalogs/{catalog_name}/items/{item_id}
/catalogs/{catalog_name}/items/{item_id}
50 requests per minute shared between the endpoints.
/scim/v2/Users/{id}
/scim/v2/Users?filter={[email protected]}
/scim/v2/Users/{id}
/scim/v2/Users/{id}}
/scim/v2/Users/
5,000 requests per day, per company, shared between the endpoints.

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:

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 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 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, so we recommend that you allow for a 5-minute delay between making subsequent calls to minimize the probability of error.

HOW HELPFUL WAS THIS PAGE?
New Stuff!