Braze Data Activation
The documented ways to move data into and out of Braze, with their limits and latency, and how Salesforce and Data 360 data reach Braze through an integration layer.
A Braze journey is only as good as the data behind it. Braze offers several documented ways to bring data in and several to send engagement data out, each with its own limits and latency. This page compares them and shows where Salesforce CRM and Data 360 fit. Every pattern here is a reference design; we validate APIs, packaging and permissions for each implementation.
The business problem
Teams often start with one path, usually the REST API, and use it for everything: bulk backfills, real-time events and nightly attribute refreshes. That runs into rate limits and makes failures hard to replay. Picking the right path per data type is cheaper and more reliable.
Getting data into Braze
Ways in
| Path | Best for | Documented limits and notes |
|---|---|---|
| REST /users/track | Server-side attributes, events and purchases | Needs the users.track permission. Up to 75 objects per request combined. Burst limit of 3,000 requests per three seconds for data-point pricing; otherwise set by contract |
| Braze SDKs | App and web behaviour | Web, Android, Swift, Cordova, FireOS, Flutter, React Native, Roku, Unity, .NET MAUI (Xamarin), TV and OTT |
| Cloud Data Ingestion | Warehouse or storage data on a schedule | Snowflake, Redshift, Databricks, BigQuery, Microsoft Fabric, S3, Azure Blob Storage, Google Cloud Storage. As often as every 5 minutes (dashboard default minimum 15) or as rarely as monthly |
| Connected Sources | Querying a warehouse without copying | Braze's zero-copy option |
| Catalogs | Product, account or content data for personalisation | CSV or API; up to 500 MB on the free tier, Catalogs Pro offers more |
| CDP and reverse ETL partners | Teams already running one | Braze lists Segment, mParticle by Rokt, Tealium and Hightouch; Census and Hightouch for reverse ETL |
Identifiers decide what happens on write
In /users/track, the primary identifiers are external_id, user_alias and braze_id, one per object; email and phone are secondary lookups. A primary identifier that matches no profile creates a new one. Purchases use reserved keys (product_id, price, currency, time, quantity), and refunds are logged as negative prices. CDI can sync attributes (including subscription statuses), custom events, purchases, user deletes, catalog items and Canvas triggers.
Getting data out of Braze
Ways out
| Path | What it delivers | Notes |
|---|---|---|
| Currents | "A real-time data stream of your engagement events" in Avro | Destinations include S3, Google Cloud Storage, Azure Blob Storage, several CDPs and analytics tools, and a Custom HTTP Connector. No Salesforce destination is listed. Included in many pro and enterprise packages, per Braze |
| Snowflake Data Sharing | A read-only share into your Snowflake account | Braze hosts it in specific AWS regions and supports others for joint customers |
| /users/export/ids | Profiles for up to 50 IDs per request | 250 requests per minute for workspaces onboarded on or after 22 Aug 2024 |
| /users/export/segment | Newline-delimited JSON files, about one per 5,000 users | To your S3, Azure or GCS bucket, or a ZIP link valid for a few hours; one export per segment at a time |
From Salesforce and Data 360
Neither Salesforce CRM nor Data 360 has a Braze connector documented by either vendor, so data flows through something you run. Two patterns cover most needs:
- Event-driven. Salesforce Change Data Capture or Platform Events go to an integration layer, such as MuleSoft or another iPaaS, which calls
/users/track. Use this when a change must reach Braze within minutes. - Warehouse-centred. CRM and Data 360 data land in a warehouse, and Braze CDI syncs from it. Use this for bulk attributes and anything that tolerates a scheduled refresh.
Data 360 specifics, including activations and data actions, are on Data 360 and Braze.
Security boundaries
Create one Braze REST key per integration, with only the endpoint permissions it needs; Braze does not let you edit a key's permissions or IP allowlist after creation, so plan to rotate rather than edit. Exports land in your storage, so apply your own access controls and retention there.
Failure handling and monitoring
Read the X-RateLimit-Remaining header and back off on 429. Keep failed batches for replay. Note that /users/merge results are not reflected in Currents or Messaging History, except for Snowflake-powered features, so downstream analytics need their own merge handling. Monitor CDI run results, API error rates and the gap between source and Braze counts.
Prerequisites and limitations
Currents connectors and Catalogs Pro depend on your Braze package; confirm Snowflake Data Sharing availability and region with Braze. Rate limits other than /users/track often fall in a shared default of 250,000 requests per hour; check the Braze limits page for each endpoint you use.
Implementation stages
- 01
Inventory data
List each attribute and event, its source, owner and freshness need.
- 02
Pick a path per data type
SDK for behaviour, /users/track for urgent changes, CDI for bulk.
- 03
Define identifiers
Agree the external_id and aliases before loading anything.
- 04
Build and backfill
Backfill through CDI or batched API calls, then switch on incremental feeds.
- 05
Set up exports
Configure Currents to your storage or analytics tool, or Snowflake Data Sharing to your Snowflake account.
- 06
Monitor
Track lag, errors and count parity.
Related
Data activation
Data activation patterns across platforms
→Salesforce and Braze
The full integration pattern
→Braze implementation
SDK, data and Canvas build
→Event-driven architecture
Change events and decoupled consumers
→Questions we hear
Is CDI real time?
Can we avoid copying warehouse data into Braze?
How do we get Braze engagement data into Salesforce?
Sources
Plan your Braze data flows
Tell us what data Braze needs and where it lives. We can recommend a path for each data type and plan the build.
