{{ sender.first_name }} {{ sender.last_name }} · {{ sender.custom_fields.company }}
{{ sender.phone }} · WhatsApp
", "text": "{{ sender.first_name }} {{ sender.last_name }} · {{ sender.custom_fields.company }}\n{{ sender.phone }} · https://wa.me/{{ sender.whatsapp }}" } } ``` Use only addresses and contact details intended for your organization. The example's BCC must be replaced with an inbox you control. BCC is optional and defaults to `[]`. A profile is not an SMTP identity: `name` remains the display name in From. A sequence's explicit From overrides `sender.email` and `sender.name`; the other profile fields, tags, signature and BCC still belong to the selected mailbox. Configure separate mailboxes when different sending identities need different defaults. PATCH omission preserves a setting. `profile: {}` clears the profile; supplying a profile replaces the entire profile object. `bcc: []` clears default blind copies. `footer: null` removes the signature. Changing these does not reset connection verification. Both `footer.html` and `footer.text` are required when a footer is configured, each limited to 10,000 source characters. The text signature is added when the message contains a plain-text alternative. A footer does not create an alternative by itself. ## Namespaces never collide There are no bare `name` or `first_name` variables. Choose the owner explicitly: | Path | Meaning | | --- | --- | | `sender.id`, `sender.email`, `sender.name` | Connected mailbox ID and effective From identity. | | `sender.domain` | Lowercase domain after `@` in the effective From email, captured with the sender. Read-only; no website fallback. | | `sender.first_name`, `sender.last_name` | Optional profile names; never inferred from the display name. | | `sender.phone`, `sender.whatsapp` | Optional profile contact strings. | | `sender.custom_fields.company` | A scalar field from the mailbox profile. | | `sender.tag` | First mailbox tag, or null. | | `sender.tags` | Mailbox tags; use `has_tag("sales")` in a condition. | | `recipient.id`, `recipient.email`, `recipient.name` | The contact being personalized. ID is null for an inline recipient. | | `recipient.given_name`, `recipient.family_name` | Saved person names. | | `recipient.custom_fields.department` | A scalar field from the person. | | `campaign.id`, `campaign.name`, `campaign.timezone` | Campaign captured at acceptance; null for standalone inline content. | | `variables.company` | Explicit request variables for direct messages or previews. Empty for normal campaign sends. | A saved-variant preview has the source campaign context even though the resulting message is standalone and does not contribute campaign metrics. Its recipient context comes from `person_id`; only the preview's explicit `to` receives the email. Direct messages use the first To address for `recipient.email`; their other person fields are null and `recipient.custom_fields` is empty. Use a saved person preview or campaign message when you need person data. ```jinjaHola {{ recipient.given_name | default("equipo") | trim | title }}.
Soy {{ sender.first_name | default("parte del equipo") }}.
{% if sender.tags | has_tag("colombia") %}Podemos conversar en horario de Colombia.
{% endif %}{{ campaign.name | default("Seguimiento") }}
``` `has_tag` requires an array and a double-quoted string, and compares exact, case-sensitive tags. The same bounded MiniJinja syntax applies to variants, direct messages and footers. See [conditional email and previews](/personalized-previews) for conditions, fallback and casing filters. Values are escaped in HTML, and field values containing template syntax stay data. Arbitrary calls, loops and `safe` are rejected. Signatures participate in the 100,000-character body limit. ## Inheritance and delivery Use `https://{{ sender.domain }}/contact/?utm_source=newsletter` in HTML or plain text to link through the sending domain. Configure HTTPS and a redirect for every domain in the sender pool before using this variable. The redirect must preserve the destination path and query string. This variable does not create DNS records, verify a website, or rewrite unrelated links. Keep the website redirect limited to its web hostnames so the separate tracking subdomain continues serving opens, clicks and unsubscribe requests. Tracking rewrites rendered links afterward according to the sequence settings. The footer is appended once inside the HTML body (or after an HTML fragment), after content rendering/generation and before click/open tracking. Its links therefore follow the campaign's tracking policy. Campaign unsubscribe content remains separate. Do not duplicate the same signature inside every variant. ### Place the signature before a postscript For authored content, place `{{ footer }}` exactly where the selected mailbox's signature belongs. Use two braces, not Liquid, triple braces or a `safe` filter. ```jinja{% if recipient.given_name | default("") | trim %}Hola, {{ recipient.given_name | trim | title }}:{% else %}Hola:{% endif %}
Podemos revisar un proceso de tu institución. ¿Te interesa?
{{ footer }}P. D. Podemos empezar por un solo proceso.
``` `footer.html` is composed into HTML; `footer.text` into the plain-text alternative. Both can use the normal sender, recipient, campaign and variables paths, conditions and filters. Configure the signature once with `PATCH /mailboxes/{id}`; the API owns composition for direct sends, clean previews and campaign delivery. No queue refresh, manual HTML concatenation or new signature endpoint is required. Each alternative independently permits **at most one** footer token. Without a token, that alternative gets the automatic signature at its end. With a token, automatic append is disabled for that alternative, even if a surrounding condition is false. No configured signature makes the token empty; a message body must still be nonempty. Use a standalone block position in HTML, not inside an attribute or another paragraph. The token is reserved for bodies: it is rejected in subject, preheader and the footer itself. Filters on the token and recursive signatures are rejected. A token-looking string in a recipient value or a quoted `default("...")` stays literal data. Normal HTML escaping and the combined 100,000-character source/output limits still apply. An explicit token with an AI generation `prompt` is rejected: generated content gets the automatic footer after generation. There is no runtime AI in an authored variant. Use `recipient.given_name` and, when appropriate, `recipient.family_name` for a known person. If the imported row only describes an institution, use its normalized custom field and a team greeting. Never invent a first/last name or infer a medical title from an institution name. A clean saved-person preview preserves these same fallbacks. For normal campaign and direct sends, explicit BCC and mailbox BCC are merged. Inherited addresses already present in To, CC or BCC are skipped case-insensitively. Explicit duplicate recipients remain a validation error. The complete envelope must contain at most 50 addresses. Every address consumes daily quota; a suppression on any address suppresses the entire message. BCC recipients see the same personalized body, so use BCC for copies, not personalized audience expansion. SMTP headers omit BCC; native transports receive the blind-recipient list privately. **Previews exclude both variant CC/BCC and mailbox BCC.** They still include the sender profile and footer, but deliver only to the requested test inbox. Test BCC separately using a direct email and controlled inboxes. At acceptance, the message captures profile, tags, footer, BCC and campaign context. By default, later edits apply to new messages; retries and idempotent replays retain their snapshot. A campaign with `live_configuration: true` refreshes sender defaults for unsubmitted deterministic messages during their normal claim, without a bulk refresh. See [campaign settings](/campaign-settings). For a definitely-unsent deterministic campaign message whose sender becomes unavailable, failover captures the replacement mailbox's defaults and replaces inherited BCC while keeping explicit variant BCC. Content with a runtime generation job waits for review before changing sender, since its generated identity may already be embedded. Accepted or uncertain submissions never undergo this reassignment.