Skip to main content
Every workspace ships with a default tenant representing your own organization. Triggers that don’t pass a tenant_id resolve against it, so branding, admin preferences, and default vendors on the default tenant apply to any un-tenanted send. You can update the default tenant’s properties like any other tenant — its ID can’t be changed.

Creating a Tenant

With the SuprSend MCP server configured in your AI assistant (Claude, Cursor, etc.), just pass a simple prompt to create tenant:
The MCP server calls the upsert_suprsend_tenant tool under the hood to create the tenant.

Tenant Properties

Managing Existing Tenants

Go to Tenants from the side navigation, then click on any tenant to view and edit its details from UI. Use below methods to manage tenants programmatically.

View a Tenant

List Tenants

Update a Tenant

Tenant ID cannot be changed after creation.

Delete a Tenant

Deleting a tenant is irreversible and removes all associated properties. It does not delete historical notification logs.

Associating users with a tenant

Associating a user to a tenant is optional. For most setups, you don’t need to — passing tenant_id at trigger time is enough for SuprSend to apply that tenant’s branding, admin preferences, vendors, and inbox scoping. Every user’s single global profile is used as-is. Explicitly associate a user to a tenant when you need one of:
  • Different channel identities per tenant — the same user needs a different push token per app, a different Slack workspace token per project, or a different email per business line.
  • Different properties per tenant — the user’s role or plan differs per customer org, and templates or workflow conditions branch on it.
  • Isolation between tenants — in a B2B SaaS, users must never leak across customer orgs. Set user_tenancy_mode: exclusive and each user is scoped to one tenant.
The workspace-level user_tenancy_mode setting controls the model:
  • exclusive — one user belongs to at most one tenant. The default for new workspaces and the standard B2B multi-tenancy model.
  • shared — one user can belong to multiple tenants, with per-tenant overrides for channel identities and properties. Per-tenant values shallow-merge on top of the user’s global profile at send time. Default for existing workspaces.
See User-Tenant Mapping for the user tenancy mode, merge semantics, and how to associate users to tenants via API / SDK / dashboard.

Next Steps