Your app's users are partitioned into workspaces (tenants). You pick a tenancy model for your org; nostackai enforces the isolation transparently and bakes the active workspace into each app JWT.

Tenancy types

  • single — all app users share one default workspace. The first user bootstraps it; everyone after joins it automatically. Your app should never show a workspace prompt.
  • multi — no default. Users arrive via an invite (which pre-assigns them) or create/join a workspace after signup. Full isolation per workspace.
http
GET /org/settings?group=tenancy    read tenancy_type
PUT /org/settings                  set single | multi

How the workspace ends up in the token

Tenant resolution happens entirely at token exchange (GET /app/{orgCode}/token). The authorizer never resolves tenancy — by the time it runs, the workspace is already a claim in the JWT.

1The token Lambda reads your org's tenancy type.
2For an existing user it picks the workspace flagged current=1.
3For a single-tenancy new user it joins (or bootstraps) the default workspace.
4For a multi-tenancy new user with no invite it issues a JWT with no tenant_id — your app then prompts them to create or join.

Detecting 'no workspace yet'

In multi tenancy, a JWT with no tenant_id is the signal to show your create-or-join screen. After the user acts, call the token endpoint again to get a JWT that includes the workspace.

Joining & switching (multi)

The platform exposes the workspace lifecycle as endpoints; your app builds its own UI on top. The common flows:

text
New user via invite      acceptinvitation -> GET /token (JWT has tenant_id)
New user, no invite      GET /token (no tenant_id) -> create or join -> GET /token
Switch workspace         list user tenants -> switch-tenant -> GET /token

Switching needs a fresh token

Setting a different workspace as current updates a flag in the database; call the token endpoint again to receive a JWT scoped to the new workspace.