Customer.io workspaces: one per country is the expensive way to go multilingual

In 1965 W. H. Smith, then the largest single book retailer in Great Britain, announced that it would move to a computerised warehouse in 1967. A warehouse run by computer needs every book to carry a number, so the retailer wanted a standard numbering system for the titles it stocked. Consultants working with the British Publishers Association's Distribution and Methods Committee devised the nine-digit Standard Book Number in 1966, and it went live in 1967.

At the same time, the International Organization for Standardization set up a working party to see whether the British scheme could work internationally. It met in London in 1968, with delegates from eight countries and a UNESCO observer, then in Berlin and Stockholm in 1969. The International Standard Book Number was approved as ISO 2108 in 1970. The ISBN.org history says that "the basic structure of the ISBN as defined in that standard has not changed". It is in use in more than 150 countries.

One numbering system, with the country carried inside the number, beat a dozen national systems that would each have needed translating into the others. A marketing team faces the same choice the day it opens Customer.io for six countries. The common move is one workspace per country. It is the expensive answer.

TL;DR: Customer.io workspaces are separate instances. The docs say "No information is shared between workspaces": each has its own people, automations, segments, metrics and API keys. One workspace per country therefore means one copy of every email per country, no segment that spans countries, no combined reporting, and a translation job multiplied by the country count. The better design for one brand in several countries is one workspace: a language attribute driving language tabs inside each message, a country attribute driving segments and conditions, and a snippet resolving country-specific links. Two constraints to know before you start. Language matching is exact, so nl-BE does not fall back to nl. And translations do not update when the default email changes: Design Studio gives you a manual Refresh from Default, every other editor makes you delete and re-add the variants. Keep workspaces separate only when the businesses are genuinely separate: different products, different data, different teams who must not see each other's people.

Why does one workspace per country feel like the safe choice?

A group we spoke to in September 2026 runs one brand across six country workspaces. Between them the countries need seven languages. Each workspace holds over a hundred emails, most in two language versions, with the tabs labelled by language and no country attached. Links differ by country, so each workspace points at its own domain. Broadcasts only go out from two of the six.

Nobody designed that. It grew one launch at a time, and each launch copied the previous country's workspace because that was the fastest way to go live. The logic is sound on launch day: a new country has a new domain, often a new legal entity, sometimes a new team. The cost appears later, when someone asks for a change to the welcome email and finds it lives in six places... twelve, counting the language versions. That twelve is arithmetic, not a measurement: six workspaces times two languages. Every copy is a place a typo can hide and a compliance edit can be missed.

What does a Customer.io workspace actually isolate?

The workspaces documentation is blunt. "Workspaces are essentially separate instances of Customer.io. Each workspace has its own people, automations, metrics, and other data." Asked directly what is shared, it answers: "No information is shared between workspaces." Each workspace is also assigned its own set of API keys.

The one bridge the docs offer is copying. You can copy workflow blocks from an automation in one workspace into another. That is a copy, not a link: the two automations drift apart from the moment you save.

Two more facts from the workspaces page shape the decision. On the Essentials plan you can create two workspaces; for a third you upgrade to Premium or delete one. And billing counts people, objects, emails sent and Data Pipelines API calls across all your workspaces, so beyond the plan tier, splitting neither saves nor costs anything on the invoice. The rest of the cost is in operations.

Inside a workspace	Shared across workspaces?	Where the docs say so
People and their attributes	No	Workspaces overview
Segments	No, and not copied	Copy workflow items
Automations and broadcasts	No, copy only	Copy workflow items
Metrics	No	Workspaces overview
API keys	No, one set per workspace	Workspaces overview, FAQ on testing
Email layouts, from and reply-to addresses	No, reset to the destination default on copy	Copy workflow items
Snippets	No, stored and sized per workspace	Snippets
Language attribute setting	No, set per workspace in Language settings	Set up your localization attribute

What does the country split cost you, concretely?

Every email exists once per country. The welcome series, the booking confirmation, the win-back, the legal footer: each is a separate object in each workspace, edited and broken separately.

No segment crosses a border. The docs on how segments work describe a segment as the way you reference any subset of the people in your workspace. Six countries in six workspaces makes everyone who booked once and never came back six segments, six automations and six sets of metrics. Comparing countries happens in a spreadsheet, after six exports.

Reporting is per workspace. The Workspace performance dashboard shows data throughput, messages sent today and delivery alerts for the workspace you are standing in. Six workspaces is six dashboards and no combined view.

Translation is multiplied. Language variants live inside a message, and a message lives inside a workspace. A change to the default copy has to be made, and re-translated, in each of the six.

Copying resets the parts that hurt. The copy-workflow-items docs are specific about what does not survive a move between workspaces. "Segments are workspace-specific, so you must re-define segment conditions on workflow items that you copy across workspaces." Attribute and event conditions do copy, with a note to review them. Layouts, reply-to and from addresses reset to the destination's defaults. Subscription preferences copy unless overridden to a specific topic. SMS, Slack and push blocks do not copy unless the destination has those channels enabled.

If that group fixed a broken link in its Dutch welcome email, the fix would need making in the Netherlands and Belgium workspaces, in two language tabs each. This is what expensive means here: not the invoice, the hours.

How does one workspace per brand handle language, country and links?

Two attributes and one snippet replace the six workspaces. Each has a constraint the docs state plainly and teams find out in production.

Language: one attribute, language tabs in every message

Customer.io's translation model is built for exactly this. You set a language attribute for the workspace under Workspace Settings, then add language variants to any message: email, SMS, WhatsApp, push or in-app. When the message sends, Customer.io matches the person's attribute value to a variant; no match means the Default message. There is no branching in the automation.

The model is not new. The release note Send multi-language newsletters the easy way! of 28 January 2022 introduced the language attribute and the Default-plus-variants pattern for newsletters. It opens with the problem it replaced: "If you wanted to send multi-language messages in the past, you needed to write complicated workflow conditions or liquid logic." Design Studio, Customer.io's newer email editor, caught up with Translate messages in Design Studio on 2 March 2026, adding language variants and AI translation inside the editor. We covered what the AI does and does not translate in our post on translating Customer.io emails with AI.

First constraint: a callout on the attribute page headed "Localization matching is strict". Customer.io does not resolve a four-letter locale such as nl-BE down to a two-letter language such as nl. If the attribute says nl-BE and the message has an nl tab, the person gets the Default message. So pick one convention and hold to it: bare language codes (nl, de, sv, fi, da, fr, en) with country kept out of the language attribute, or full locales with a tab for every one. For one brand in several countries, bare codes are the right call. The group's language-only tabs were fine; their error was using workspaces for the country axis.

Second, from the getting-started page: "We do not automatically update translations when you change the default template." In most editors the documented route is to delete the language variants and re-add them. Design Studio is the exception: its Refresh from Default option regenerates selected variants from the current default, with or without AI translation. That alone is a reason to build the multilingual emails there. A related caution from the same page: Liquid renders attribute values as stored, so "make sure you store values in native languages".

Country: an attribute, a segment, an action condition

Country is a separate fact about a person, so it gets its own attribute: a two-letter country code on the profile, set by whatever system creates the person. Everything the six workspaces did for country becomes a condition.

A segment on the country attribute replaces the workspace as the audience boundary. The group's two broadcasting countries become one segment with two values. A segment across all six countries, which did not exist before, is a segment with no country condition at all. Action conditions on individual messages take the same attribute.

Legal footers, sender names and regulatory copy that differ by country are Liquid conditionals on the same attribute, inside the one email. It is the pattern from several apps sharing one Customer.io workspace. A profile attribute does the routing a second workspace would otherwise do, for the price of a condition rather than a copy.

Links: a snippet that resolves the country URL

The one-domain-per-country problem is the one that convinces teams they need a workspace per country. It is a snippet.

Customer.io's snippets are shared chunks of content usable anywhere Liquid is, referenced as {{snippets.<name>}}, and they can contain Liquid of their own. Create one, say site_url, holding a conditional on the country attribute:

{% if customer.country == 'nl' %}https://example.nl{% elsif customer.country == 'de' %}https://example.de{% elsif customer.country == 'be' %}https://example.be{% else %}https://example.com{% endif %}

Every link in every email then reads {{snippets.site_url}}/book, and the right domain resolves per person at send time. Change a domain once, and every email follows.

The localisation docs say snippets are not auto-translated, and that the right place for language logic is a Liquid conditional inside the snippet itself. So one snippet can carry both axes: a country conditional for the domain and a language conditional for the path. Two limits: the default maximum for one snippet is 16 KB, and all snippets in a workspace must total under 5 MB. A country map is nowhere near either. Keep the else branch: the snippets docs say profile Liquid needs a fallback so it degrades gracefully in anonymous messages.

Which attribute should drive what?

The question a send has to answer	Driven by	Mechanism
Which language does this person read?	The workspace language attribute	Language tabs on the message, exact match, Default as the fallback
Which country's domain, footer and sender?	A country attribute	A snippet conditional for URLs, Liquid conditionals for copy, action conditions on messages
Who is in this audience?	A segment on country, language and behaviour	One segment, one automation, one set of metrics
Who may see and message these people?	Workspace access	Assigned per workspace by an Account Admin, per the workspaces page

The last row is the honest one. The workspaces docs say you assign access based on workspace, so a team member can have full access to one and partial access to another. If a country team must not see or message another country's customers, that is the control the docs offer, and an attribute does not provide it. Who may send inside a single workspace is a separate question of roles, which we covered in our post on the execute permission.

When are separate workspaces the right call?

Separate workspaces are the right design when the businesses are genuinely separate. The docs' own framing is that the isolation exists to prevent sharing information and potentially messaging the wrong person. That is a feature when:

• The products are different, with different events, different attributes and no shared customers. Two data models in one workspace is a naming collision waiting to happen.
• The data must not sit together. A legal entity whose customer data has to be walled off, or a client account an agency runs alongside others.
• The teams must not see each other's people. The docs assign access per workspace, so that wall is drawn at the workspace.
• It is a staging environment. The docs say workspaces can be a sandbox, each with its own API keys, with finished workflow items copied into production.

Separate workspaces are the wrong design when the only thing that differs is language, domain or country. Those are attributes.

The grey zone is one brand where one country is regulated differently and its compliance team wants a hard wall. Keep that country separate and merge the rest; five into one still removes most of the duplication. If your countries also differ in channel, one on WhatsApp and one on LINE, that is still one workspace: channel choice by country is a condition too.

How do you get from six workspaces to one?

We have done this. For Kip, an Australian pet boarding and daycare group, we consolidated two Customer.io workspaces into one: 200,000+ profiles and 80+ live campaigns merged with zero disruption. The order of work matters more than the tooling.

1. Decide the attribute conventions before you move a single person. Language codes bare or full locale, country as a two-letter code, and the exact attribute names. The localisation attribute docs describe an automation that rewrites a badly formatted language attribute with a Create or Update Person action. That is the tool for normalising what each workspace stored differently.
2. Build the snippet and the language tabs in the destination first, on one email, and test every country and language pair before touching the rest.
3. Copy the workflows across and re-attach what the copy drops: segments, layouts, from and reply-to addresses, and any subscription topic overrides.
4. Move people country by country, with the country attribute set on the way in. The cut-over logic is the same as any migration into Customer.io, and the old workspaces stay live until the last one is empty.
5. Delete nothing until the metrics agree. Deleting a workspace permanently removes its automations, emails, people, deliveries and metrics, and the docs say deleted workspaces are not recoverable.

The ISBN working party met in London, Berlin and Stockholm because agreeing one numbering system was cheaper than translating between many. The Customer.io version of that meeting is one afternoon deciding attribute names. Everything after it is a condition, not a copy.

If you are running one brand across several workspaces and want the consolidation scoped before anyone touches production, that is work we do. Tell us how many workspaces you have.

Frequently asked questions

Does Customer.io share data between workspaces?

No. Customer.io's workspaces documentation states that no information is shared between workspaces, and describes each workspace as a separate instance with its own people, automations, metrics and other data. The one documented crossing is copying workflow items between automations in different workspaces, which copies the blocks but drops the segment conditions and resets layouts and sender addresses to the destination's defaults.

Can I send one email to people in two different Customer.io workspaces?

Not from one message. A broadcast or automation lives in a workspace and can only reach the people in that workspace, because workspaces share no people. To reach two countries with one send, both countries' people need to be in the same workspace, with a segment on a country attribute choosing the recipients.

How does Customer.io decide which language version of an email to send?

Customer.io matches the person's language attribute, the one you set in the workspace's Language settings, against the language variants on the message. If a variant matches, the person receives it; if none matches, they receive the Default message.

Does nl-BE fall back to nl in Customer.io translations?

No. The localisation attribute docs state that matching is strict and that Customer.io does not fall back from a four-letter locale such as nl-BE to the two-letter code nl. A person whose attribute is nl-BE receives the Default message unless the email has an nl-BE tab.

Can I copy an email from one Customer.io workspace to another?

Yes. The copy-workflow-items feature lets you copy workflow blocks, including messages, from an automation in one workspace into an automation in another. Segment conditions are not copied and must be re-defined, and the layout and the from and reply-to addresses reset to the destination's defaults.

Do Customer.io translations update when I change the default email?

No. The docs say Customer.io does not automatically update translations when you change the default template. In most editors you delete the language variants and re-add them; in Design Studio, Refresh from Default regenerates selected variants from the current default.

How many workspaces can I have in Customer.io?

On the Essentials plan you can create two workspaces, and the docs say a third requires upgrading to the Premium plan or deleting a workspace first.

When should I use separate Customer.io workspaces instead of one?

Use separate workspaces when the businesses are genuinely separate: different products with different data, customer data that must be walled off, teams who must not see each other's people, or a staging environment. If the only differences are language, country or domain, those are attributes, and one workspace with language tabs, a country attribute and a URL snippet is the cheaper design.

Sources

• Customer.io, Workspaces in Customer.io, documentation, updated 14 September 2026.
• Customer.io, Translate your messages, documentation, updated 14 September 2026.
• Customer.io, Set up your localization attribute, documentation, updated 14 September 2026.
• Customer.io, Reusing content with snippets, documentation, updated 14 September 2026.
• Customer.io, Copy workflow items, documentation, updated 14 September 2026.
• Customer.io, How segments work, documentation, updated 14 September 2026.
• Customer.io, Workspace performance dashboard, documentation, updated 14 September 2026.
• Customer.io, Send multi-language newsletters the easy way!, release note, 28 January 2022.
• Customer.io, Translate messages in Design Studio, release note, 2 March 2026.
• ISBN.org, ISBN History, read 21 September 2026.
• NerveCentral, Kip case study.