Merge Tags

Merge tags let you insert personalised data into your emails at send time. Instead of a generic greeting like "Hello there", you can write "Hello {{first_name}}" and SendBeam will replace the tag with each subscriber's actual first name when the email is delivered. The result feels personal, even when you're sending to thousands of people at once.

What Are Merge Tags?

A merge tag is a placeholder wrapped in double curly braces: {{tag_name}}. When SendBeam processes a campaign for delivery, it replaces each merge tag with the corresponding value from the recipient's contact record. If the contact doesn't have a value for that field, the tag is replaced with its fallback — or with nothing, if you didn't give it one.

Merge tags can be used in two places:

• Subject line — Personalised subject lines can significantly improve open rates. For example: {{first_name}}, your order summary is ready. Tags and fallbacks only — conditions belong in the body.
• Email body — Use merge tags anywhere inside the email content, including inside text blocks, button labels and link URLs.

The same tags work in automation emails and templates.

Available Merge Tags

SendBeam supports the following merge tags:

• {{first_name}} — The contact's first name, as stored in their profile.
• {{last_name}} — The contact's last name.
• {{email}} — The contact's email address. Useful for account confirmation emails or personalised download links.
• {{custom_fields.key}} — Any custom field stored on the contact, for example {{custom_fields.company}}. Values are HTML-escaped, so a field cannot inject markup into your email.
• {{workspace_name}} — Your workspace's name — the business the email comes from, as shown at the top of the app. Sign off with it instead of typing the name into every email, and a rename reaches every template at once.
• {{sender_name}} — The From name the workspace sends as (Settings → Workspace). Usually the same as the workspace name, sometimes a person's.
• {{unsubscribe_url}} — A unique, one-click unsubscribe link generated for each recipient. Put it wherever you want the unsubscribe link to appear.
• {{web_version_url}} — A "view in browser" link to the campaign's own page at sendbeam.io/c/<campaign id>. On a real send it is personalised for that recipient (their merge tags filled in, their unsubscribe link working); the plain page shows the campaign with empty fields. The Footer block in the email builder includes it. Empty in automation and transactional emails, which have no page.

The Merge tags buttons under the campaign editor insert these at the cursor — First Name goes in as {{first_name|there}}, with the fallback text selected so you can type over it; Business name and Sender name are the two workspace tags. Custom fields you have declared get a button each.

Fallback Values

Not every contact has a value for every field. Put a pipe and some text inside the braces and that text is used whenever the value is missing, empty or only whitespace:

• {{first_name|there}} — "Hi Ada," for Ada, "Hi there," for a contact with no first name.
• {{custom_fields.plan|free}} — the contact's plan, or "free" when the field is not set.
• {{web_version_url|https://example.com/archive}} — a link of your own where there is no campaign page (automation and transactional emails).

The rules, in full:

• Fallbacks work everywhere a tag does: the subject line (both lines of a subject-line test), the email body and the plain-text version, in campaigns, automations, templates and the API.
• The fallback is everything after the first |, exactly as typed. Spaces are kept — | there gives " there" — so put the pipe right after the tag name.
• Fallback text is treated like a contact value: in the HTML body it is escaped, so it cannot add markup or links. Plain text if you want plain text.
• To show a literal pipe, write \|: {{custom_fields.team|Sales \| Support}}. That is the only escape; any other backslash is left alone. A fallback cannot contain braces.
• An empty fallback ({{first_name|}}) is the same as no fallback: the tag renders as nothing.
• A fallback never replaces a value that exists. A first name of "0" or "n/a" is shown as stored.

Conditional Content

Some content is for some recipients only — an offer for customers on a paid plan, a nudge for contacts with nothing in a field, a line that changes with what someone has spent. Wrap it in a condition:

{{#if custom_fields.plan is "pro"}}
  <p>Your Pro perks this month…</p>
{{else}}
  <p>Upgrade to Pro and…</p>
{{/if}}

A recipient whose plan is "pro" gets the first part; everyone else gets the second. The {{else}} part is optional — without it, recipients who fail the test get nothing where the block was.

A condition is a field, an operator and usually a value:

• The field is any merge tag from the list above, without its braces: first_name, email, custom_fields.plan, web_version_url…
• The operator is written in words, the same ones segments use: is, is not, contains, does not contain, starts with, ends with, is set, is not set, is greater than and is less than. Text comparisons ignore case, so is "pro" matches "Pro" as well.
• The value goes in straight double quotes — "pro" — or stands bare when it is a number: is greater than 100. Numbers compare as numbers, dates as dates. is set and is not set take no value.

Conditions people reach for:

• {{#if first_name is set}}Hi {{first_name}},{{else}}Hi there,{{/if}} — the same result as Hi {{first_name|there}},; a condition earns its place when more than one word changes.
• {{#if custom_fields.lifetime_value is greater than 100}} — where your store sends order events, a customer's spend to date.
• {{#if email ends with "@yourcompany.com"}} — a note only colleagues see.
• {{#if web_version_url is set}} — a "view in browser" line only where there is a page to view (campaigns have one; automation emails do not).

The rules, in full:

• Conditions work in the email body and the plain-text version, in campaigns, automations and templates — in the visual builder, type them into a Text block. They do not work in a subject line: a subject is one line, a fallback does that job there, and the Review step says so.
• A condition can contain another condition, and no deeper.
• Merge tags inside a condition work as they do anywhere else, fallbacks included, and values are escaped in the HTML body exactly as they are outside one.
• A value cannot contain a double quote. Characters the editor stores as HTML entities — an ampersand, a non-breaking space — are read as the characters themselves, so is "Sales & Support" matches what is stored on the contact.
• A condition SendBeam cannot evaluate — an operator it does not know, a field that does not exist, a {{/if}} with no opening, a block nested too deep — is treated like an unresolved tag: the block goes out exactly as typed, tags and both parts, and the Review step lists it under unresolved tags with the fix.
• An unsubscribe link inside a condition does not count as the email's unsubscribe link, because some recipients would never see it; SendBeam appends its own at the bottom, as it does when there is none. Keep {{unsubscribe_url}} outside any condition.

Unresolved Tags

A tag SendBeam does not recognise is not replaced — it goes out exactly as typed, braces and all, to every recipient. So it is checked before anything is sent:

• The campaign wizard's Review step lists every {{…}} in the subject lines, the body and the plain-text version that will not resolve, says where each one is, and suggests the tag you probably meant (frist_name, First_Name, custom.plan and {{ first_name }} all point at the right tag). Send now and Schedule stay off until the tags are fixed or you tick Send anyway.
• A draft's own page shows the same list, and its Send button asks for an explicit Send anyway while any remain.
• Send test sends the copy as-is — seeing the literal braces in your own inbox is the point — and names the tags in the dialog afterwards.
• Templates and automation email steps show the same warning while you edit, and an automation's activation check repeats it.

custom_fields.key is checked against Settings → Custom fields: a key nobody has declared is flagged, with the nearest registered field suggested where there is one. A misspelled key that slips through still renders as nothing (or its fallback). The Review step also mentions, as information rather than a warning, when an email has no {{unsubscribe_url}} (SendBeam adds an Unsubscribe link at the bottom on send) or no {{web_version_url}} (recipients get no "view in browser" link).

Testing Personalisation

Before sending a campaign to your full audience, verify that merge tags resolve correctly — with real data, not placeholders.

Send test is available from the Email step and the Review step while you are composing (the builder saves a draft as you go, so there is always a campaign to test), and on the campaign's own page afterwards.

1. Click Send test. The dialog is addressed to the email you sign in with; add more addresses separated by commas if a colleague should see it too.
2. Optionally pick a contact under Render as. The copy is then rendered with that contact's data — the surest way to check a custom field — while still going to the addresses you entered. Its unsubscribe link is bound to the test, never to the contact.
3. Without a contact, the test goes out with your own first name filled in for {{first_name}} and no custom fields, so fallbacks show.
4. Check your inbox within a minute or two. The view-in-browser link in a test opens the draft.

If merge tags appear unresolved (e.g. you see the literal text {{first_name}} in the email), check that:

• The tag name is spelled correctly, in lowercase, with double curly braces and no spaces inside them — the Review step will have listed it under unresolved tags.
• A custom-field tag uses the exact key stored on the contact, for example custom_fields.company.
• The editor has not split the tag across formatting — check the HTML view for stray tags inside the braces.