Skip to content

Enterprise accounts and teams

The MQTT portal separates who you are (login) from which MQTT tenant you are working in (devices, subscriptions, topics). That lets one person belong to multiple tenants—with different roles on each—under their own organization or someone else’s.

How it fits together

flowchart TB
    User[Portal user — email login]
    Ent[Enterprise — your organization]
    T1[Tenant A — MQTT isolation]
    T2[Tenant B — MQTT isolation]
    User -->|owner| Ent
    Ent --> T1
    Ent --> T2
    User -->|member on another org| T2
  • Portal user: One account per email address. You sign in once.
  • Enterprise: The organization you create at registration. It can own one or more tenants (separate MQTT namespaces, billing, and quotas).
  • Tenant: Where MQTT clients, read-only subscribers, history, and subscriptions live. Topic paths still use this id: {account_id}/{client_id}/… (the portal may show it as tenant id or account id—same value).
  • Team membership: Links your user to a tenant with a role. Permissions apply only inside that tenant, never across tenants.

You might be Owner on tenants under your enterprise and Member on a tenant owned by another customer’s enterprise.

Roles on a tenant

Role Typical use
Owner Billing, subscriptions, add-ons, inviting teammates, changing roles
Member Day-to-day operations: MQTT clients, MQTT/REST tokens, pause/resume
Data Manager InfluxDB read tokens only (when the Influx integration add-on is enabled)
Action Owner Member Data Manager
Change subscription or add-ons Yes
Invite people or change roles Yes
Manage MQTT clients and subscriber tokens Yes Yes
Create Influx read tokens (add-on required) Yes Yes Yes

Owners see a Members item in the portal menu to invite colleagues by email.

Invitations

An Owner enters an email address; the invitee receives a link such as:

https://<your-portal>/team-invite/<token>

The link is valid for 48 hours. The flow:

  1. Open the link (see tenant name and intended role).
  2. Log in or create a portal user (verify email if new).
  3. Accept the invite and land in that tenant’s dashboard.

The invite email must match the logged-in user. After acceptance, you can switch between tenants you belong to from the portal header.

First sign-up

When you create a portal account, the system provisions a default tenant automatically and opens the portal on that tenant. You do not need to pick a tenant on first login unless you have also been invited elsewhere.

Signing in again

  • One tenant — you go straight to the dashboard for that tenant.
  • More than one tenant (you own multiple or accepted invites) — you see a Choose a tenant screen listing every tenant you can access, with your role on each. Pick one to continue.

Switching tenants

Open Settings → MQTT tenants to switch the active tenant or create another tenant under your enterprise (Owners only). You can also use the API (POST /api/auth/active-tenant) to set the active tenant cookie. All devices, billing views, and tokens refer to that tenant only.

Automation (Mgmt REST API)

With the Mgmt REST API add-on, Owners can use a portal REST token to create sibling tenants and manage members programmatically (POST /api/v1/subscriber/tenants, /api/v1/subscriber/members/…). See Team and tenant management.

What does not change

  • MQTT topic layout and broker ACLs remain per tenant id.
  • REST history tokens and subscriber APIs are still scoped to a single tenant.
  • Dataset reseller invites (consumer subscriptions to someone else’s data product) are separate from team invites.

For operators

Greenfield deployments use the enterprise schema described in the MQTT SaaS operator doc ENTERPRISE_TENANCY.md in the isr-mqtt-server repository. Existing databases are not migrated in place; plan a full database reset when adopting this model.