Authentication & provisioning

Everything you do with MeshedFlow — joining the mesh, signing manifests, reading your telemetry — is scoped to your tenant. This page covers how a tenant is provisioned, where your credentials come from, and how they’re scoped.

How a company is provisioned

A tenant is an attribution and policy unit on a shared delivery fleet. When MeshedFlow provisions your company, onboarding is zero-touch:

1. You’re invited. The contact on the account becomes the tenant’s first member — an owner with a pending invite.

2. A branded invite email goes out. The email carries a one-time invite link back to the portal login (https://app.meshedflow.com/login?invite=…). If the mailer is unconfigured or the message bounces, an operator can hand you the invite token directly — both paths land on the same acceptance screen.

3. You set a password. Accepting the invite lets you set a credential and sign in. From then on you use the portal for everything.

Additional teammates are invited the same way — an owner or operator invites them by email, and they accept and set a password. One email address is one person: you can’t be invited into two tenants under the same address.

Where your credentials come from

When your tenant is provisioned you get an SDK integration set. Three values go into the loader:

• signalingUrl — your tenant’s signaling/WebSocket endpoint. This is the wssEndpoint returned at provisioning time (for example wss://signal.meshedflow.com:8445/ws). It’s where the SDK connects for peer discovery.
• streamId — the identifier for one stream, formatted as <customerId>:<name> (for example cust_20260808_eb8790f7:live-demo). The <customerId> prefix is what ties the stream to your account.
• authToken — the SDK JWT you embed in your build. It carries your customerId, which is what the control plane uses to select your signing allowlist and to scope your data.

The <customerId>:<name> boundary rule

A stream belongs to your account when its id is your customerId, or starts with your customerId followed by a separator — one of :, /, -, or _. The separator matters: it stops acme from claiming a stream called acmecorp-live. Concretely, for customerId = cust_20260808_eb8790f7:

cust_20260808_eb8790f7:live-demo  ✓ belongs to you  (":" separator)
cust_20260808_eb8790f7/vod/movie  ✓ belongs to you  ("/" separator)
cust_20260808_eb8790f7            ✓ belongs to you  (exact match)
cust_20260808_eb8790f72:live      ✗ different customer (no separator after your id)

The <customerId>:<name> form is the convention we recommend, and it’s the same boundary the API uses to decide which streams, metrics, and reports you’re allowed to read.

Token lifetime and rotation

SDK tokens are long-lived on purpose — you embed one in a build and it has to outlive any single portal session. The SDK token issued at provisioning is valid for 90 days. Rotate it by issuing a fresh token from the portal and shipping it in your next build; an already-issued token runs until it expires.

Note

The public verification key the SDK fetches for signature checks is a separate key from your authToken — you never handle the signing key, and rotating your token doesn’t affect verification. See Content signing.

Tenant-role scoping

Your session is scoped to your own tenant. A tenant-role token:

• sees only its own streams — list, metrics, timeseries, export, and pilot reports are all narrowed to streams that match your customerId under the boundary rule above;
• manages only its own content-origin allowlist;
• is refused platform-wide reads that have no per-customer meaning (asking for those returns 403).

For exactly which endpoints a tenant token may and may not call, see the HTTP API reference.

Related

• Content signing & origins — how your customerId selects the signing allowlist.
• HTTP API reference — the endpoints your token can call.