Customer.io test workspace: stage email changes before they go live
Every year, coins made by the Royal Mint are put on trial. The Trial of the Pyx is a court of law, with a jury, a presiding judge and a verdict. The Royal Mint Museum dates it to at least 1282. The Goldsmiths' Company, which runs it, records a public trial in 1248 with twelve citizens of London and twelve goldsmiths on the jury. So it has run since the thirteenth century at the latest. Elizabeth I gave the Company the jury in 1580, and since the Coinage Act of 1870 the trial has sat at Goldsmiths' Hall in London.
The method is the interesting part. Through the year, one coin is set aside from every batch of every denomination struck, sealed in bags of 50 and locked in the pyx, the box that gives the trial its name. The Goldsmiths' Company says that normally comes to more than 50,000 coins. A jury of the Company's freemen, sworn in by the King's Remembrancer, counts and weighs them, measures diameters and assays the metal against standard trial plates. The oldest surviving plate dates from 1477. The verdict arrives two to three months later.
The Mint tests its own coins on the production line. The trial is credible because it happens somewhere else, on coins pulled before they circulate, judged by people who did not make them. A client asked us for the same thing in September 2026, in different words: somewhere to test email changes before customers see them.
TL;DR: Customer.io has no staging environment as a product, but its docs say a second workspace can serve as "a sandbox to set up testing/staging environments". It gets its own API keys and shares nothing with production. Set it to test email delivery and every email it generates lands at one address you choose. Every plan on the pricing page allows at least 2 workspaces, so the workspace is not the cost. The cost is the copy step. Segment conditions, email layouts, from and reply-to addresses do not follow a message across workspaces, so promote to production is a process you design, by hand or with the App API. If your team changes one email a fortnight, skip the workspace: test sends, Queue Draft and Design Studio's publish gate already do the job.
Does Customer.io have a staging environment?
Not as a named product. What it has is workspaces, and one FAQ on the workspaces docs page answers the question directly. Workspaces were not designed for testing, the docs say, but they can be used as "a sandbox to set up testing/staging environments". Then the sentence that matters: "Each workspace is assigned its own set of API keys and are completely separate from your other workspaces."
That separation is what makes a second workspace a staging environment rather than a folder. Nothing you do in it can reach a production profile, because production does not know it exists. It can reach whoever you seed into it, which is why the send behaviour comes next.
The docs then hand you the safety catch. When you create a workspace you set its default send behaviour from three options:
- Send messages normally. Everything sends as the workflow says.
- Test email delivery. In the docs' words: "Emails will send to a defined test address; other messaging types (Slack, webhooks, etc.) send as normal."
- Never send messages. Delivery is disabled on every channel. The docs add: "You might choose this option for test workspaces."
In test email delivery, emails go out from Customer.io's own test domain and address ([email protected]) rather than your verified domain. The docs say delivered, opened and clicked metrics cannot be tracked back to the workspace. Here that is a feature: test traffic stays off your sending domain and out of your real numbers. One detail to know before setup: the test address is one address for the whole workspace, not one per person. Account Admins and Workspace Admins choose it.
Push has its own version of the same advice. The push QA docs say "we recommend that you keep separate development/test and production workspaces". Even where an iOS sandbox shares certificates with production, they still recommend a separate test workspace with the "Send to sandbox" option turned on. Where several apps share one account, see Customer.io multiple apps in one workspace first.
What does a second workspace cost?
Only what the pricing page and the docs say. The Customer.io pricing page has a Workspaces row in its Usage and Billing table: Essentials 2, Premium Unlimited, Enterprise Unlimited. Essentials starts at $100 per month; Premium starts at $1,000 per month, billed yearly. The same page confirms the Essentials limit: "You can create two workspaces", and past that you upgrade to Premium or delete one.
The workspace itself is not a line item, but usage is. The docs' billing FAQ says Customer.io bills "based on people, objects, emails sent, and Data Pipelines API calls across all your workspaces", so a test workspace's profiles are profiles. Seed it with a small, named set of test people, never a copy of production, which would be customer data with weaker controls around it. On Essentials the allowance is 5,000 profiles across the account, so junk in staging eats production's allowance. For a developer-led team starting from nothing, the Builder plan is a different route in.
Why promoting to production is the step nobody budgets for
The workspaces FAQ is blunt: "No information is shared between workspaces." And again: "Workspaces are essentially separate instances of Customer.io. Each workspace has its own people, automations, metrics, and other data." Staging cannot leak into production, and it cannot push into production either. Nothing syncs. Every change you prove in staging has to be carried across by something.
Customer.io does give you a carrier. The copy workflow items docs let you copy blocks from one workflow into another automation, "even if your automations are in different workspaces". Newsletters got the same treatment in a release note dated 17 October 2022, and the workspaces FAQ points at this feature as the route from test to production.
Read the copy page to the end, though. Its list of what will not carry across workspaces starts with segments. Email layouts and reply-to and from addresses reset to the destination's defaults, with warnings reading "Email layout was reset to default" or "Headers were reset to default". Action conditions vary by type.
| Action condition on the copied block | Copied across workspaces? | What the docs say to do |
|---|---|---|
| Segment conditions | No | Re-create the segment in the destination and re-add it as a condition. |
| Attribute conditions | Yes | Review them: the attribute has to exist in the destination. |
| Event data conditions | Yes | Copied for event-triggered automations; review them. |
| Subscription preferences | Sometimes | A preference overridden to a specific topic resets to Use automation settings. |
| SMS, Slack, push blocks | Only if enabled | The destination has to have the channel switched on, or the block cannot be copied. |
One behaviour works in your favour. Messages copied into an active automation default to Queue Draft, the hold-before-send setting, whatever their original setting, so a promoted email cannot fire at real people until someone flips it to Send Automatically.
The copy feature moves workflow blocks and nothing else: segments do not transfer, and saved templates, global styles and the people you seeded are outside its scope altogether. The docs describe workspaces as completely separate, so plan on rebuilding or scripting those.
We have crossed this boundary in the other direction: for Kip we consolidated two Customer.io workspaces into one, 200,000+ profiles and 80+ live campaigns merged with zero disruption. It took a plan, because nothing moves between workspaces on its own.
Three ways to promote a change from staging
Pick one and write it down; the team that does not choose ends up doing all three.
1. Copy workflow items in the UI. The documented route. Copy the changed block into the production automation, then work through the resets: layout, from address, reply-to, segment conditions, subscription topic. The copied message arrives as Queue Draft, so test-send from production, inspect a draft, then switch it to Send Automatically.
2. Script it with the App API. The App API overview says the API "lets you update automation actions, messages, newsletter variants". It authenticates with an App API key as a Bearer token, and each workspace has its own keys. So a script holds two: read the message from staging, write it into the matching action in production. Most endpoints allow 10 requests per second, far more than a promotion script needs. This is the content-as-code pattern; see how the App API turns Customer.io content into code. The overview names automation actions, messages and newsletter variants as what it updates; segments and layouts are not on that list, so give them a home in production first.
3. Rebuild by hand, using staging as a rehearsal. Prove a copy or Liquid change in staging, then make the same edit in production and test-send from there. Slower per change, no reset surprises, and production's audit trail stays the record of what changed.
Whichever you choose, production's own pre-send checks belong in the promotion checklist, starting with the Design Studio readiness score.
Four ways to check an email before a customer sees it
A staging workspace is the heaviest of four tools; the other three are already in your account.
| Tool | What it does | Limits the docs state | Best for |
|---|---|---|---|
| Test send | Sends the email to addresses you enter, with a chosen person's data merged in | Up to 25 addresses per send; event-triggered automations only test with people who have performed the event | Rendering and Liquid on one email |
| Queue Draft | The automation runs for real people but generates drafts instead of sending | Drafts kept 30 days; set per message; changing a trigger or filter does not re-evaluate existing drafts | Auditing a live workflow's output before anything sends |
| Design Studio publish (beta) | Edits to a linked email autosave but do not reach the automation until you click Publish | Global styles are not autosaved; publishing compiles unpublished component and style changes too | Editing a live email with a review gap |
| Second workspace | A separate instance with its own people, automations and API keys, emailing one test address | Nothing shared with production; the copy step; billing counts its profiles | Integration and SDK testing; frequent changes by several people |
The Queue Draft docs use the word themselves. "Think of this as a staging feature: everything works as it normally would, but you can audit the output before it gets sent out in the real world." It is the default for a new message, and drafts not sent within 30 days are deleted for you. The Design Studio publish gate is still labelled beta. Edits autosave, but the automation does not change until you click Publish, "which gives you time to review and make updates safely before they go live". Queue Draft plus a publish gate is a staging process for one live email with no second workspace. The practicalities are in how to edit a live campaign in Customer.io.
When a second workspace is worth it, and when it is not
Set up a staging workspace when at least one of these is true:
- Several people change copy on live campaigns often. Test sends cover one email at a time. A staging workspace lets someone rebuild a whole welcome series and run test people through it without touching production's drafts or metrics.
- A dev team needs to integrate. This decided it for that client. Engineers need to identify people, fire events and trigger transactional messages from a staging build of the product. For that client it means outside US peak hours, while nobody on the marketing side is watching. A workspace with its own API keys means their build cannot touch a production profile, however wrong the payload.
- Push or in-app messaging is involved. The push docs recommend separate test and production workspaces, and device tokens and SDK builds are the last things to test on a production audience.
- Workflows call third-party webhooks. The webhook action docs put it in bold. "We strongly recommend only using test data with any third-party service you do not have a trusted relationship with." A test workspace seeded with test people is how you honour that.
Skip it when:
- You change one email a fortnight, or thereabouts. Test send, Queue Draft and the publish gate are enough, and they leave no copy step behind.
- The real problem is who can push live. A staging workspace does not stop a colleague editing a live automation; production is one click away. Permissions do: Customer.io's execute permission separates the people who can change things from the people who can make them go.
- You are on Essentials and already use both workspaces. Staging would cost you a product or an upgrade.
A useful test: if you cannot name the person who will own the promotion step, you are not ready for a staging workspace. You are ready for Queue Draft.
How we set one up
For that client, the plan looks like this.
- Create the workspace and make it look different. Name it so nobody could mistake it for production, and give it a custom colour that shouts.
- Set send behaviour to test email delivery. One address for the whole workspace, chosen from your team members, so invite a shared inbox as a team member and pick it. Email is the only channel this redirects; SMS, push, Slack and webhooks still send for real to the test people you seeded.
- Restrict access and hand over the staging keys. Access is assigned per workspace for everyone but Account Admins. Developers get staging, and their build never learns production's keys. Identify a small set of named test people there, nothing else.
- Rebuild the changing campaigns in staging. Copy workflow items from production to save typing and fix the resets on the staging side too. Then run test people through while the developers fire events at whatever hour suits them.
- Promote on a schedule. Copy the changed blocks back, work through the reset list, test-send from production, check the readiness score, then switch the copied message to Send Automatically. One person owns this, and it is written down.
- Keep staging small. Delete junk profiles, because billing counts them. Never import production people.
The Trial of the Pyx works because the test happens outside the Mint, on coins that have not reached anyone, with a named jury delivering the verdict. Your staging workspace is the pyx. The promotion checklist is the jury. Skip either and you are back to testing coins on the production line.
Designing the workspace split, the promotion step and the permissions around it is the work our Customer.io agency does every week. Tell us about your setup and we will say which of the four tools fits.
Frequently asked questions
Does Customer.io have a staging or sandbox environment?
Customer.io has no product called a staging environment, but its docs say a second workspace can be used as "a sandbox to set up testing/staging environments". The workspaces docs state that each workspace has its own API keys and that no information is shared between workspaces.
Does a second Customer.io workspace cost extra?
The Workspaces row on the Customer.io pricing page reads Essentials 2, Premium Unlimited, Enterprise Unlimited, so a second workspace is within every plan's allowance. Usage still counts: the docs say Customer.io bills on people, objects, emails sent and Data Pipelines API calls across all your workspaces, so test profiles use the same allowance as production.
Can I copy a campaign from a test workspace to my live workspace?
You can copy workflow items between automations in different workspaces using the Copy to option in the workflow builder. The copy workflow items docs say the copy will not carry segments, email layouts, reply-to and from addresses or some action conditions. Layout and header settings reset to the destination's defaults. Messages copied into an active automation arrive set to Queue Draft, so nothing sends until you change it.
What does "Test email delivery" do in a Customer.io workspace?
Test email delivery sends every email the workspace generates to one defined test address instead of the recipient, while channels such as Slack and webhooks send as normal. The workspaces docs add that these emails go out from Customer.io's test domain, so delivered, opened and clicked metrics cannot be tracked back.
Is Queue Draft the same as a staging environment?
Queue Draft is a per-message staging feature inside a live workspace, and the sending behaviour docs describe it as one. The automation runs for your production audience and generates drafts you audit before anything sends, and drafts are deleted after 30 days. A staging workspace is the tool for integration and SDK testing instead.
Can I edit a live campaign email in Customer.io without a test workspace?
Yes: Design Studio autosaves edits to a linked email, but the automation does not reflect them until you click Publish, according to the publish changes docs. With Queue Draft on the message and a test send from the editor, that is a staging process for one live email.
Do I need a test workspace to test push notifications?
Customer.io's push QA docs recommend separate test and production workspaces for push, especially where the two do not share credentials. Even when an iOS sandbox uses the same certificates as production, the docs still recommend a separate test workspace with the "Send to sandbox" option turned on.
Sources
- Workspaces in Customer.io, Customer.io docs, read 21 September 2026
- Test push notifications, Customer.io docs, read 21 September 2026
- Edit linked messages and publish changes, Customer.io docs, read 21 September 2026
- Copy workflow items, Customer.io docs, read 21 September 2026
- Copy newsletters across workspaces, Customer.io release notes, 17 October 2022
- About the App API, Customer.io docs, read 21 September 2026
- Test your emails, Customer.io docs, read 21 September 2026
- Queue Draft (sending behaviour options), Customer.io docs, read 21 September 2026
- Send and receive data with webhook actions, Customer.io docs, read 21 September 2026
- Pricing and plans, Customer.io, read 21 September 2026
- Trial of the Pyx, Royal Mint Museum, read 21 September 2026
- The Trial of the Pyx, The Goldsmiths' Company, read 21 September 2026
- Kip case study, NerveCentral
Want this working in your Customer.io workspace?
It's what we do all day for SMBs—strategy, automations, deliverability and hands-on execution.
See how we work as a Customer.io agency →
