Staging

There is no test mode and no test API key. To run your integration from staging, use a second workspace. It is a separate copy of everything: contacts, events, segments, templates, campaigns, journeys, webhooks, push apps, API keys and sending domains. Nothing in it touches your live workspace.

This is how Customer.io, Iterable and Braze handle staging too: a separate workspace rather than a test key or a test mode, so staging behaves exactly as production does.

Set one up

1. Create the workspace. In the dashboard, open the workspace switcher and choose Create workspace; name it something like “Acme – Staging”. You become its owner. The number of workspaces a login can own depends on its plan: Free 1, Starter 2, Pro 5, and Enterprise as agreed, so a staging workspace needs a paid plan.
2. Verify a sending domain in it. A domain can be verified in only one workspace, so use a subdomain of your live domain, such as staging.example.com. Sending from its own domain also keeps a bad test run off your live domain’s reputation.
3. Create an API key there, in the dashboard’s API keys settings, with the scopes your staging app needs. See Authentication.
4. Point your staging app at that key. The base URL is the same; the key decides the workspace.
5. Recreate what the app depends on: the templates it sends (publish them — sends use the published version), webhook endpoints, push apps and their credentials, topics.

What to expect

• It sends for real, to anyone. Staging is not a sandbox that swallows mail. Use addresses you own, or your team’s, as test contacts. Fake addresses bounce, and bounces count against the staging domain’s reputation and can pause its marketing sends.
• Every rule applies as in live: suppression, consent, quiet hours, message limits, idempotency, rate limits and webhooks.
• Usage counts. A staging workspace draws on its owner’s plan like any other workspace they own: emails, contacts and AI credit are shared across the owner’s workspaces, and it doesn’t come with an allowance of its own.

Moving tested content to live

Until the dashboard can copy between workspaces, copy a template through the API with a key from each workspace:

GET /v1/templates/{id}
Authorization: Bearer <staging key with templates:read>

Then create it in live from the response’s name, schemaVersion, blocks and theme:

POST /v1/templates
Authorization: Bearer <live key with templates:write>
Content-Type: application/json

Set plainTextOverride, if it has one, with PATCH /v1/templates/{id}. A transactional template is published as version 1 when created. Campaigns, journeys and segments are rebuilt in live; ids differ between workspaces, so anything that names another resource (a segment in a campaign, a template in a journey step) must point at the live one.

Checking content without a second workspace

For “does it look right?”, the live workspace already has safe tools that send nothing to customers: test sends to members or a saved test list, previews rendered as a chosen contact, segment preview and count, and journey simulation.