Tenancy and organizations

A tenant is the organization boundary used by InBlack product data, billing, membership, and authorization. Users may belong to multiple tenants and select one active context at a time.

Request scoping

Authenticated product requests resolve tenant context from the API-key tenant, a validated X-Tenant-ID, or an allowed membership/default context, depending on the middleware used by that service. Database helpers set app.current_tenant_id inside transactions so row-level security can enforce the selected tenant.

Callers must not treat a UUID header as authorization. The middleware validates the principal’s relationship to the selected tenant before the product handler runs.

Membership roles

The standard membership vocabulary is owner, admin, accountant, member, and viewer. Those roles map to the owner, admin, accounting, and view-only RBAC templates. Product/module/action entitlements and billing pillar access determine the final authorization result.

Portal’s custom-role editor stores tenant-specific role IDs and entitlement rows. Built-in role names such as developer, marketing, and fulfillment exist in the RBAC catalog but are not standard invite-role enum values.

Practice links

A Practice tenant can link to client organizations. Links have their own lifecycle and can be active or archived; they do not merge client data into the practice tenant. Accountants select a client context and the APIs continue to enforce that target tenant’s data and authorization boundaries.

See Practice connection summary and Switching context for the current operator behavior.