Skip to content
WeZend

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

BrazeWeZend
Users / external_idContacts (matched on email/phone)
Custom attributesCustom fields
Custom eventsEvents (POST /v1/events)
SegmentsSegments (live rules)
CanvasJourneys
Frequency capping / quiet hoursSending policy (built in)
Currents (event export)Warehouse sync + webhooks
Content CardsIn-app inbox
Intelligence SuitePredictive 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