Enterprise engagement
How to switch from Braze
An engineering-led migration: user export via API, custom events remapped to the events endpoint, Canvases rebuilt as journeys, and Currents replaced by warehouse sync.
A sprint of engineering time over 4–6 weeks of parallel running
| Braze | WeZend |
|---|---|
| Users / external_id | Contacts (matched on email/phone) |
| Custom attributes | Custom fields |
| Custom events | Events (POST /v1/events) |
| Segments | Segments (live rules) |
| Canvas | Journeys |
| Frequency capping / quiet hours | Sending policy (built in) |
| Currents (event export) | Warehouse sync + webhooks |
| Content Cards | In-app inbox |
| Intelligence Suite | Predictive scores + AI coach |
Read this first
Braze migrations are engineering projects, not marketing projects — your Braze value lives in SDK instrumentation and event pipelines, and that's what actually moves. The good news: WeZend's surface is deliberately simpler (plain REST, no SDK required), so the destination is less code than the origin.
Step 1 — Map the identity model
Braze keys users on external_id; WeZend matches contacts on email/phone and accepts your own IDs as custom fields. Decide the mapping up front: export external_id → email/phone pairs, and store external_id as a custom field (braze_external_id) so historical references never go dark during the transition.
Step 2 — Export users, import contacts
Export your user base via Braze's user-export APIs (segment-scoped exports work well — export segment by segment to keep provenance). Global unsubscribes and email bounces come first, into Audience → Suppressions — same iron rule as every migration on this site. Then import users with attributes mapped to custom fields.
Step 3 — Re-point the event stream
Wherever your backend calls Braze's track endpoints, call POST /v1/events instead — or in parallel during the transition; dual-writing events for two weeks is the safest pattern:
await fetch("https://api.wezend.com/v1/events", {
method: "POST",
headers: { "X-API-Key": process.env.WEZEND_API_KEY, "Content-Type": "application/json" },
body: JSON.stringify({
contact: { email: user.email },
event: "order_completed",
properties: { value: 499, currency: "DKK" },
}),
});
Keep event names identical to your Braze taxonomy — rebuilt segments and journeys read naturally, and your analysts keep their vocabulary.
Step 4 — Canvases become journeys
Canvas steps translate directly to journey nodes: entry rules → triggers, Delay/Decision Split/Action Paths → delay and branch nodes, message steps → send nodes (all six channels). Frequency capping and quiet hours move from per-Canvas configuration to a platform-wide sending policy — one place, every send, no per-Canvas drift.
Rebuild in revenue order, test-enroll each journey, and let the parallel period judge: pause a Canvas only after its journey twin has run cleanly on real traffic.
Step 5 — Replace Currents
If Currents feeds your warehouse or BI, replace it with warehouse sync (profiles + events to your own database) plus delivery webhooks for real-time consumers. Most teams find those two cover every Currents consumer they actually had.
What does NOT come along
- Message engagement history — export reports for your records; WeZend analytics start fresh.
- Braze's ML segments (predicted churn etc.) — recompute with the built-in predictive scores once events flow; they're segmentable the same way.
- Content Cards content — recreate as in-app inbox messages; the embed model is comparable.
Go-live checklist
- Identity mapping decided; braze_external_id stored as custom field
- Global unsubscribes + bounces imported as suppressions FIRST
- Users exported segment by segment, imported with attribute mapping
- Event stream dual-written to POST /v1/events during the transition
- Revenue-critical Canvases rebuilt as journeys and test-enrolled
- Sending policy configured (caps + quiet hours) platform-wide
- Currents consumers repointed to warehouse sync / webhooks
- Canvases paused one by one, only after journey twins run clean
Frequently asked about switching from Braze
Braze prices on MAU — how does that translate?
It doesn't, deliberately. WeZend charges for messages sent (plus your plan), not monthly active users — storing profiles and streaming events costs nothing. Teams coming from MAU pricing usually find the bill finally correlates with what they actually do: sending.
We rely on Braze's mobile SDKs for push. What replaces them?
Mobile push runs over FCM: connect your Firebase server key and register device tokens with POST /v1/push/subscribe from your app code. Web push needs only the one-script SDK. In-app messaging maps to the in-app inbox API rather than an SDK layer — simpler, and your app controls the rendering.
Start free in minutes
- No credit card
- EU data residency
- 6 channels, one API
- GDPR built in
One platform. Every customer interaction.
Replace your patchwork of messaging APIs, CDP and automation tools with a single engagement platform built for scale.
No credit card required · EU data residency · 99.99% uptime SLA