White-label? We've got you: every email in your merchant's logo and colors

If your platform sends email on behalf of your customers, each of them wants their own customers to see their brand, not yours. With five merchants, five templates are manageable. With a hundred, every copy change becomes a hundred changes, and sooner or later someone gets the wrong logo.

Now one journey and one template go out in each merchant's logo and colors. The brand lives in your data, not in the template.

How it works

1. Store each merchant's brand in a custom object, for example merchant_brand, with fields like logo_url, primary_color and name. It arrives through the API, an import or a sync, like the rest of your data.
2. Add a Look up record step to your journey, right before the email. Pick the record type, how to find it and which fields to load, and save it under a name, for example brand.
3. In the email editor, bind the colors and the logo to that name. Next to any color there's a { } button (Use a variable for…): type brand.primary_color, and the swatches you pick become the fallback. On an image, use brand.logo_url, with the image you already had as the Fallback image URL.

Each run looks up its merchant's brand and the email goes out with it. The copy can use it too: {{brand.name}} in the subject or the body.

How to find the record

• By an ID this run carries: the merchant ID on the event that triggered the journey (event.merchant_id), a person attribute, or a field of another record you already looked up.
• Linked to the person: follow your CDP relationships, up to three hops (person → merchant → merchant brand).

When several records match, If several match picks one by a field, the newest for example. Without that rule none is loaded: never a random one.

What happens when something is missing

• The journey never stops. If a merchant has no record, the fields stay empty and the email goes out in your default branding.
• A color that isn't a color (blank, mistyped) uses the fallback instead of breaking the design.
• Before sending, Boom checks every value: if a field carries code, a script or a javascript: link, it's removed.
• When you publish, Boom checks the contract: if your email uses brand.primary_color and the step doesn't load it, publishing is refused and tells you which field to add.

The email step's preview runs the lookup on a real event, so you see the email in that merchant's brand. Its variables are split into Content and Style, so copy and look are easy to tell apart.

Not just for brands

Look up record loads any custom object. Find the order the event names and send {{order.total}} on WhatsApp, or load the account's plan before a reminder. The fields work in emails, WhatsApp, SMS, Instagram and Messenger messages, HTTP requests and events.

From the API and MCP

Records load with POST /api/v1/cdp/custom-objects. Over MCP, an agent can create the type, load the brands and build the whole journey with the Look up record step, and publishing applies the same checks.

Available now

Look up record is on in every workspace. The editor shows the fallback colors; to see a merchant's real brand, use the email step's preview in the journey. The step's details are in the journeys documentation.