Implementing Wunderkind + Braze Signals – Identity, Mailability, and List Growth Plumbing at Scale

When teams evaluate Wunderkind + Braze, the real question isn’t “Can it send emails?”—it’s “Will this integration respect our identity model, subscription logic, and compliance rules without breaking what already works?”

This post walks through the core technical patterns Wunderkind uses to “play nice” with Braze: durable identifiers and URL parameters, Braze API usage, and how Signals handles mailability, list growth, and prospect vs. customer state.

Durable identity: bxid and Braze profiles

Wunderkind sits in front of Braze as an identity and decisioning layer. It recognizes more of your web traffic and ties that behavior to Braze-ready identifiers, often expanding identification from 3–5% of traffic to roughly 40–60%.

To keep that identity stable from inbox to onsite, the integration uses Braze-native IDs in links:

• In Braze, each user has a braze_id. Wunderkind’s standard Link Template appends bxid=} (plus UTMs) to email URLs so every click carries a durable key back to site.
• When a user clicks through, Wunderkind reads bxid, ties the session to the right Braze profile, and can later trigger Signals (cart, browse, catalog) against that same person rather than a fragile cookie.

On the back end, Signals uses Braze’s profile model directly. Before triggering a Canvas, Wunderkind:

1. Calls /users/export/ids to confirm the user exists and to retrieve aliases or identifiers.
2. If needed, creates a user_alias (for example wknd_email_id) with /users/alias/new and upserts the profile via /users/track so Braze has an email-backed record to target.
3. Triggers your Canvas using /canvas/trigger/send, passing the canvas_id, the alias, and a canvas_entry_properties payload that includes items, purpose, and user type (prospect vs. customer).

Batches are grouped by Canvas ID and capped at 50 recipients to stay efficient at volume.

Respecting Braze’s mailability and subscription model

Wunderkind is additive on top of Braze; it does not override Braze’s consent logic. There are two layers here:

1. Braze-side checks
   • Canvas Entry Audience is configured with filters like “Email Available is true” and any stricter subscription or suppression rules you require.
   • Send Settings use Braze’s native permission checks so only subscribed or opted-in users receive Signals-powered messages.
2. API-level subscription handling (for capture and opt-out flows)
   • To check mailability or subscription state, Wunderkind uses endpoints like /users.export/ids and /subscription/user/status to read email_subscribe and group membership where needed.
   • When a user unsubscribes via a Wunderkind-powered touchpoint, Wunderkind can write that back using /email/status for global email opt-out, or /subscription/status/set for group-level unsubscribes.
   • If a user unsubscribes before Braze has a profile, Wunderkind can create one via /users/track with a clearly labeled alias (for example, “Unsubscribed Via Wunderkind”) and set email_subscribe to unsubscribed, preventing accidental future mailings.

Net effect: Braze remains the source of truth for who is mailable; Wunderkind reads and updates that truth rather than keeping a parallel list.

New subscribers, list growth, and customer state

Wunderkind’s Identity Network is optimized to recognize more visitors and drive more capture, which then flows into Braze in real time.

New subscribers and extra fields

When a visitor submits a Wunderkind-powered form, the Braze API integration can:

• Create or update the user via /users/track with email, phone, and any relevant external_id, using the Braze REST endpoint appropriate for your cluster.
• Attach them to one or more subscription groups by including subscription_groups in the payload so they immediately qualify for the right Canvases and campaigns.
• Set attributes_to_merge to populate Braze custom_attributes for things like acquisition source, signup experience, or lifecycle stage.

These profiles are then addressable for both your “native” Braze programs and Signals-driven Canvases.

Prospect vs. customer logic

Many brands differentiate journeys based on whether someone is a prospect or an existing customer. Signals supports two complementary patterns:

• Attribute-based: Use Braze custom_attributes (such as customer_state) to segment users in Canvas Decision Splits. Signals passes a UserType field (for example, "prospect" or "customer") in canvas_entry_properties, and Braze uses that to branch messaging and cadence.
• Subscription-group–based: Treat membership in a “customers” subscription group as your canonical flag, checking that via subscription APIs or Braze segmentation before entry.

From a practitioner’s perspective, you keep using the same Canvas tools—Segments, Decision Splits, Exit Criteria, and Rate Limiting. The only difference is that entry is driven by high-intent Signals, not just simple web events.

What this means for your Braze architecture

Operationally, the integration is designed to be low-friction:

• You connect Braze to Wunderkind via an API key with scoped permissions (Canvas, Content Blocks, Purchases), configured once in Wunderkind’s Integration Hub.
• Wunderkind auto-creates Braze assets: a set of email Content Blocks, a “Wunderkind Signals” Link Template (with bxid and UTMs), and a library of Signals Canvases (cart, product, category, back-in-stock, price drop, low stock) following recommended cadences.
• You remain in Braze to finish Canvas buildout—drag in the Content Blocks, wire up your creative, set entry/exit rules and frequency caps, and then go live.

For marketing ops and engineering, the key reassurance is that Wunderkind uses Braze’s own APIs, identifiers, and mailability rules, rather than introducing a parallel user store. You preserve your current data model and compliance posture, while unlocking more identified users, more list growth, and more high-intent journeys from the same Braze environment.