Using tenants

Tenants isolate traffic. Messages in one tenant never reach another, even if the channel names match.

Where tenants come from

Tenants are assigned when issuing an access token. If the master token has a tenant_prefix, get-token prepends it so the access token stores the physical name (example: prefix paint. and request lobby → paint.lobby). Publish and subscribe use that physical name.

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 and subscribe call takes an exact tenant name.

Examples (SDK):

• Publish: client.publish("prod", "orders", payload)
• Subscribe: client.subscribe("prod", "orders") (or a pattern such as 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.