Skip to main content

Team accounts

MailSlurp supports team accounts for organizations. Team accounts allow you to create multiple users and share inboxes and email addresses and other resources between them. You can also enable SAML SSO for your team and use your existing identity provider (IdP) to manage user access.

Structure​

MailSlurp account access starts with a root account user, then expands into organization-level access control and environment-level isolation.

Core model:

  • A root account user creates and manages organizations.
  • Each organization contains child users with custom access profiles and/or per-user permissions.
  • Child users can sign in through the email portal or through SAML SSO.
  • Organizations include a default environment and can add additional environments (for example staging) to isolate entities and keys.
  • Users with access to the same environment work with the same environment-scoped entities.
  • Users can switch environments in the app, and each environment has its own inboxes, phones, and API keys.

MailSlurp organization structure

Organization overview​

Organizations are a way to group users and resources together. Organizations can be used to share inboxes, email addresses, and other resources between users. Organizations enable SAML single-sign to MailSlurp via your own identity provider (IdP).

Name and slug​

Each organization has a unique slug - this is an ID that is used in login links and API calls. You can use a more descriptive name for the organization name.

User access options​

Users can access an organization by logging in via email one-time codes. You can also enable SAML SSO for your organization to use your existing identity provider (IdP) to manage user access. See the dedicated SAML SSO setup guide for full setup and provider-specific configuration.

Users wishing to access an organization via email access link can do so at https://app.mailslurp.com/organization/[YOUR_SLUG]. You can disable email access in the organization settings.

email login

SAML SSO IdP​

If you configure single sign-on (Okta, Azure AD, etc) for your organization then users will be redirected to your IdP to login. Once logged in they will be redirected back to MailSlurp with a valid session. You can initiate the login via your IdP or at https://enterprise.mailslurp.com/login?slug=[YOUR_SLUG].

enterprise login

Organization settings​

You can configure organization settings to add custom branding and to disable user login via email link. This can be found on the organization overview page.

Disable email login

Logo and branding​

You can configure a logo to be displayed on login screens and within the app using the organization settings page. A square icon with a background color is recommended.

Disable email login​

MailSlurp allows team members to login via their email and a verification code. This can be disabled in the organization settings to ensure only SAML SSO is used for login. Disabling email login with block users like so:

Block email login

Managing organizations​

You can manage organizations as the subscription holder account using the MailSlurp dashboard.

Create a team​

To create an organization navigate to the organizations page in the dashboard. You can create a new organization or invite users to an existing team.

Managing user seats and membership​

Manage seats and users from the organization area in the MailSlurp dashboard.

Seat capacity​

Subscription plans include a base number of user seats. If you reach your seat limit, increase capacity from the subscription page before inviting more users.

Add users​

To add users to an organization:

  1. Open your organization in the dashboard.
  2. Go to the users/team members section.
  3. Invite the user by email.
  4. Assign the correct role/permissions for their responsibilities.

Remove users and reclaim access​

When a user leaves a team or no longer needs access:

  1. Remove the user from the organization.
  2. Rotate or revoke any API keys, webhook endpoints, or automations tied to that user.
  3. Reassign ownership of critical resources to an active admin/operator.

Removing users keeps organization access current and frees seats for new team members.

Seat management best practices​

  • Review active users regularly and remove inactive accounts.
  • Keep a small buffer of spare seats for onboarding or incident response.
  • Separate production and non-production teams where possible to reduce accidental access crossover.

Users table

Roles and permissions​

Organization access should follow least-privilege rules: grant only the permissions a user needs for their job, and keep high-privilege access limited.

Access model:

  • Permissions are assigned per user and can also be managed with custom role/group patterns.
  • Different users can have different rights for organization settings, login policy, SSO controls, entity operations, and reporting access.
  • Keep access scoped to actual responsibilities and review assignments regularly.

Permission behavior to know:

  • Permissions are managed at the organization level.
  • Shared inboxes are created with team access enabled (allowTeamAccess), and organization inbox listings expose those shared resources.
  • Organization-scoped views can be read-only depending on the permissions granted to a user.
  • Login policy controls (for example disabling email login and enforcing SAML) should be restricted to trusted high-privilege users.

Recommended controls:

  1. Keep the number of high-privilege users small and reviewed regularly.
  2. Grant temporary elevated access only when required, then downgrade afterward.
  3. Separate production and non-production organizations so permissions cannot accidentally cross environments.
  4. Pair role changes with audit/event monitoring so access updates are traceable.

Audit logs and activity history​

Enterprise accounts can enable audit logging for security operations and compliance workflows.

What audit logs include:

  • Entity lifecycle events such as create, update, and delete actions.
  • Authentication and authorization events such as sign-in attempts, access grants, and policy-controlled access changes.
  • Organization governance events such as user membership updates, permission changes, and configuration updates.

Operational capabilities:

  • Search audit records by time range, actor, event type, and target entity.
  • Export audit history for incident response, internal reviews, and external audits.
  • Retain event history for compliance and long-term governance requirements.

If you need enterprise audit logging enabled for your account, contact sales via the pricing page.

Environment isolation and switching​

Use environments to isolate entities and credentials inside the same organization.

How it works:

  • Every organization starts with a default environment.
  • You can create additional environments (for example staging) for workflow or lifecycle separation.
  • Users in the same selected environment see and operate on the same environment-scoped entities.
  • Environment resources are isolated: inboxes, phones, API keys, and related entities in one environment are not mixed with another.
  • Organization users can switch environment context in the app to work with the correct isolated dataset.

Why this matters:

  • Keeps non-production traffic separate from production communication.
  • Reduces accidental cross-environment sends.
  • Gives teams consistent access controls while preserving resource isolation per environment.

Implementation guidance:

  1. Keep one environment per lifecycle stage (default, staging, prod patterns).
  2. Issue and rotate API keys per environment and per automation pipeline.
  3. Name resources with clear environment intent (staging-otp-*, prod-billing-*).
  4. Verify the active environment before running tests, bulk sends, or automations.

Sharing across organizations​

Sharing behavior is organization-scoped by default, with explicit patterns for cross-organization collaboration.

Important scope note:

  • The public v2 OpenAPI does not expose cross-organization sharing endpoints.
  • Organization creation, membership, role management, and org switching are handled in the MailSlurp dashboard.

What is shared natively:

  • Team members in the same organization can access shared resources (for example inboxes created with team access enabled).
  • Organization inbox endpoints expose inboxes created for team access.

What is isolated:

  • Resources in one organization are not automatically visible in another organization.
  • Permissions, SSO setup, and user roles are managed per organization.

Cross-organization collaboration patterns:

  1. Add the same users to multiple organizations with the minimum required permissions, then switch context when needed.
  2. Use webhooks or forwarding to pass events/messages between environment organizations.
  3. Use guest portals or downstream systems if external teams need controlled access without full org membership.

Tip: if your goal is strict environment separation, prefer isolation first and use webhook/forwarding integration for selective data sharing.

SAML SSO​

SAML SSO configuration is documented in a dedicated page so this guide can stay focused on organization structure, access models, and governance.

Continue here: