# Staging

Running your integration from staging: a second workspace, not a test mode

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](/docs/api/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:

```http
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`:

```http
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.