Using tenants

Tenants are namespaces for isolation. Messages in one tenant never reach another tenant, even if channel names are the same.

Where tenants come from

Tenants are assigned by your administrator when issuing an access token.

Your token contains a list of allowed tenants (example: ["prod", "test"]). You can only publish/subscribe inside those tenants.

How to use a tenant

Every publish/subscribe command includes a tenant field.

Examples (conceptually):

• Publish: { "tenant": "prod", "channel": "orders", "payload": "..." }
• Subscribe: { "tenant": "prod", "channel": "orders" }

One tenant per operation

Each publish or subscribe command targets exactly one tenant. There is no way to subscribe to channels across multiple tenants with a single rule. If you need messages from tenant_a and tenant_b, you must create two separate subscriptions — one for each tenant.

No wildcards or regex for tenants. Unlike channels, tenant names do not support any pattern matching — no *, #, >, or regular expressions. Both in tokens (tenant_ids) and in runtime operations, you always specify exact tenant names. This keeps tenant boundaries strict and prevents accidental cross-tenant data leakage.

Best practices

• Use separate tenants for dev, stage, prod.
• For multi-customer systems, give each customer their own tenant.
• Use composite tenant names when you need both environment and customer isolation: prod-customer123, dev-acme, stage-42. Other patterns work too: region-env (eu-prod), project-env (billing-stage), etc.
• Keep tenant names simple and stable. See Limits for allowed characters and max length.