Skip to main content
Alforse is built around a hard split between customer operational data and system metadata. The API keeps tenant data isolated so that one customer organization cannot read another organization’s contracts, payments, files, or audit events.

System metadata

Tenant registry, plan entitlements, subscription state, license state, and system health information. This metadata is separate from contract content.

Tenant data

A tenant’s operational data: contracts, payments, dynamic fields, workflow, files, and tenant-scoped audit. Every tenant-scoped row carries a tenant boundary.
A tenant is a customer organization — what you log into with a tenantSlug.

How this shows up in the API

A tenant access token (scope: "tenant") carries tenantId, roleCode, and subjectScope as claims and can only call tenant-scoped endpoints. There is no separate tenant header to set, and tokens are not interchangeable across tenants — see Authentication.

Administration layers

LayerRole examplesResponsibilityData boundary
Tenanttenant admin and other tenant rolesMembers, subjects, fields, workflow, saved views, files, export policyLimited to the current tenant
Workspacetenant member / viewer rolesDay-to-day contract workGoverned by role and workflow permissions
See Roles & Permissions for how tenant roles and modules work in practice.

Applications map to this split

ApplicationPlaneAudience
apps/dealsTenantBusiness users doing daily contract work
apps/consoleTenantTenant admins managing their own organization
apps/apiTenant and system servicesThe shared backend behind the product and direct API integrations

Tenant creation

Tenants are created through an Alforse onboarding process or by redeeming a code (POST /auth/redeem). There is no public “sign up with just an email” path in production. See Plans & Editions for how codes and plans relate, and Quickstart to get started.