Customer.io email in several languages and markets.

By Alexander Andersson · Updated 1 Nov 2026 · Customer.io's docs checked 1 Nov 2026

How do Customer.io's language variants work?

One message holds every language: you draft the Default message, click Add language, and pick the languages you need. Customer.io's guide to it is "Translate your messages", and variants work on email, SMS, WhatsApp, push and in-app messages [1]. Because the variants live inside the message editor, you do not need a branch per language in the automation [1].

Each new variant starts from the Default. You can tick Auto-translate with AI, which needs Customer.io AI switched on in the AI settings, or leave it off and paste in a vendor's translation [1]. Auto-translate covers body text, subject lines, preheaders and image alt text. It does not translate images, layouts in the rich text and code editors, text inside Liquid, snippets, or custom Design Studio components unless you detach them first [1]. Customer.io's own advice is to review every result, because generative AI can make mistakes [1].

Variants do not follow the Default. Customer.io does not update translations when you change the Default message. In most editors you delete the language and add it again; Design Studio has Refresh from Default, which overwrites the chosen variants with new AI output or with the Default itself [1]. Either way, re-translating after a late fix to the Danish copy wipes any hand edits in the Swedish variant.

How does Customer.io choose each person's language?

It reads one attribute, which you name under Settings, Workspace Settings, Language settings [2]. The values must be a two-letter language code such as da, or a language and region joined by a dash, such as sv-SE. Case does not matter; the dash does [2].

Matching is strict. Customer.io does not fall back from a language and region code to the bare language: a person stored as nl-BE does not get the nl variant, they get the Default [2]. Decide early whether your markets store de or de-DE, and add variants with exactly those codes. If your data uses underscores or full language names, Customer.io documents a Create or Update Person action that rewrites the attribute with Liquid or JavaScript [2].

Anyone with no match gets the Default message, and so does anyone whose language you later delete from the message [1]. Count each market's people with no value before a send: they will all read the Default language.

How do you handle footers and legal lines per market in Customer.io?

Snippets are the shared piece. A snippet is common content you reuse across messages, usable anywhere Liquid works, including subject lines and SMS. It can hold HTML and Liquid, it is capped at 16 KB by default, and a snippet cannot be renamed [5]. HTML in a snippet used in a subject line shows as raw code [5].

Because auto-translate skips snippets, Customer.io's advice is to put language conditions inside the snippet file [1]. A legal line, though, follows the market rather than the language. A Swedish speaker in Finland still needs the Finnish company line, so branch the legal snippet on a market or country attribute, for example {% if customer.market == "de" %}, and keep the attribute name your own.

In Design Studio, headers and footers can be custom components. Editing the source file updates every message that references it, and a message linked to an automation or send needs its changes published [6]. To translate a component's text you must detach it first, and a detached component no longer receives changes from its source [6]. That makes a translated footer a copy, not a shared block: decide which footers stay shared and which become one per market before you translate. Design Studio rules can also show or hide a component by the reader's language preference [7].

The unsubscribe page has its own languages. Customer.io translates its standard copy into 29 languages; your topics and headers need your own translations, each made live separately. Adding a lang parameter to the unsubscribe URL in each variant sets the page's language; without it, the reader's browser decides [8].

One message with variants, or one message per market?

Variants fit markets that differ only in language. Customer.io's older guidance still describes three ways to split by language: separate messages behind action conditions, Liquid conditions inside one message, and one automation per language behind segments. It notes that the Liquid method mixes every language's stats together, while one automation per language keeps them apart [3]. With variants, the Metrics tab shows each language under the message, and a one-time send's Overview shows metrics per language [4].

One constraint decides some programmes: you can A/B test translated messages in one-time sends only. Add languages to a message in an automation and that message can no longer be A/B tested, even if you delete the languages later [1].

Holm Coffee is a fictional demo brand. Its fixture has three markets, three languages and three currencies, mapped here onto Customer.io's two approaches.

The trade is plain. Variants are one build, one send and one place to fix the copy, but every fix to the Default means re-translating, and a reduction claim written for Denmark lands in Sweden's stricter scope. Editions are three builds, each with its own market's facts. A workable rule: use variants when only the language differs, and an edition when anything a lawyer or a finance team would check differs. The price-reduction scopes are fixture data, not legal advice.

Where does Customer.io keep data for European brands?

In the region you choose when you create the account: the US, or the EU, whose data center Customer.io says is in Belgium [9]. Every workspace in an account lives in the same region, and Customer.io does not migrate accounts between regions except in extenuating circumstances [9]. Region does not change feature availability apart from a few listed exceptions; automatic geolocation collection, for one, is off by default in the EU [9]. An EU account should name its region when it calls Customer.io's APIs [9].

Also on.

Klaviyo · Braze · Salesforce Marketing Cloud Next · Voyado · Customer.io · Iterable