MailSlurp logo
Search documentation

Environments

Isolate staging, production, and workflow-specific resources inside one MailSlurp organization.

View MarkdownAgent setup

MailSlurp environments let one organization run separate organization-like workspaces for different teams, stages, or workflows. Each environment has its own resource inventory, including inboxes, phone numbers, API keys, webhooks, usage, and operational context, so staging, QA, production, or customer-specific work can stay separated without forcing every environment into a completely independent team account.

Use environments when you need to:

  • segregate users so each person can enter only the environments they are assigned to
  • isolate resources such as inboxes, phone numbers, domains, webhooks, and API keys per environment
  • keep staging, QA, test, and production activity out of each other's data and workflows
  • connect SAML or OIDC identity provider claims to MailSlurp roles and environment grants
  • provision and deprovision organization users from an identity provider with SCIM, then use SCIM groups or SSO role mappings to control environment access

For identity-provider setup, start with:

Why environments matter

Use environments to:

  • keep test traffic away from production resources
  • prevent users from seeing environments they should not access
  • 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.

Environment selection changes the active MailSlurp account context. When a user switches environment, they see that environment's resources and settings rather than the default organization's resource inventory.

  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

Restrict organization access by role or user

When an organization is granted access to an environment, the grant can apply to all organization users or be restricted to selected organization roles or users.

Use role restrictions when your identity provider assigns MailSlurp roles through SAML, OIDC, or SCIM group role sync. For example, map an Entra group to a PTEST user role, then restrict the PTEST environment grant to that role. Users mapped only to a DEV role can remain in the same organization without seeing or switching into PTEST.

For step-by-step provider examples, see Entra SAML role mapping, Google Workspace SAML role mapping, Entra OIDC and SCIM environments, and Okta OIDC and SCIM environments.

Use user restrictions for small exceptions, such as a named release owner who needs temporary access to a locked environment.

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.