Skip to main content
Merge tags pull contact and trigger data into an email at send time. This page is the reference for the syntax and for which fields resolve.

​
Syntax

A merge tag is a field name inside double braces. Write the spaced form, {{ firstName }}. It is the form used throughout Brew and across these docs.
Variable names are case-sensitive. {{ firstName }} matches a field named firstName, not firstname. Triple braces ({{{firstName}}}) are not recognized and ship as literal text in the email.

​
Where They Work

  • Email body
  • Subject line
  • Preview text
In the TypeScript SDK, the subject and previewText on a sendEmail node take the same syntax. They are evaluated against the trigger payload at fire time.

​
What You Can Reference

​
Contact Properties

Every contact carries three default properties that resolve as merge tags. subscribed, created_at, and updated_at are filter and sort fields rather than merge tags. Brew keeps them out of the variable picker because they are bookkeeping. If you want a date in email copy, store it as a custom property. Manage Contacts owns the full contact field list and the reserved names you cannot use for custom properties.

​
Custom Properties

Any custom property resolves by its name, so a property named plan is {{ plan }}. Custom properties are the way to personalize on anything Brew does not track by default.

​
Trigger Payload Fields

In an automation, every field declared on the trigger event resolves by name. An event carrying orderId gives you {{ orderId }}. Keep payloads flat. Nested objects are harder to reference in email content, which is why Build an Automation recommends a flat schema.
Connected sources declare their own payload fields, and each integration page lists what its events carry. See Stripe, Clerk, Shopify, Stytch, Supabase, WorkOS, and RevenueCat.

​
When a Tag Does Not Resolve

An unresolved tag renders as empty rather than as an error, and the email still sends. That makes a typo silent, so it is worth checking a tag before a large send. Three things cause this:
Names are case-sensitive and must match the declared field exactly. {{ firstname }} does not match a field named firstName.
Some fields exist only on certain events from a provider. Stripe’s invoiceNumber, for example, is declared on invoice.created, invoice.paid, and invoice.payment_failed, but not on invoice.upcoming.
Brew strips some provider fields before an automation sees them, so they never resolve even though the provider sends them. Stripe’s opaque object IDs work this way. The Stripe customer ID still reaches the contact as the stripe_customer_id custom field, so filter on it there.
Use a fallback wherever an empty value would read badly. Hi {{ firstName }}, becomes Hi , for a contact with no name. Hi {{ firstName | there }}, reads correctly either way.

​
Check Before You Send

Send yourself a test and confirm each tag resolves, and that the fallback reads naturally when it does not. QA an Email Before a Big Send covers the wider pre-send routine.

​
Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

ChatGPT/Claude Integration

Click “Open in ChatGPT” at the top right of any page to explore it further with ChatGPT or Claude.