Environments

Environments

Environments let one organization keep separate sets of inboxes, phone numbers, API keys, and related workflows. The most common use case is keeping staging and production isolated without creating a completely separate team account.

Why environments matter

Use environments to:

  • keep test traffic away from production resources
  • reduce accidental sends from the wrong workflow
  • give teams a predictable context for launches, canaries, and QA
  • preserve governance consistency while still isolating resource sets

Typical environment model

Most teams start with something like:

  • default for day-to-day or initial setup
  • staging for release rehearsal and integration testing
  • production for live customer messaging

The exact names matter less than the operating discipline behind them.

  1. Give each environment a clear purpose.
  2. Issue API keys per environment and rotate them independently.
  3. Name resources so the environment is obvious at a glance.
  4. Confirm the active environment before tests, bulk sends, or launch checks.

Good patterns

  • use staging inboxes and phone numbers for CI and pre-release validation
  • use production environments for live campaigns and transactional workflows only
  • pair environment isolation with Roles and permissions so production access stays deliberate

When to use a separate organization instead

Use a separate organization when you need a stronger administrative or identity boundary than one shared organization can provide. Use environments when the same core team needs shared governance with isolated resources.