One tenant language
Companies, memberships, teams, and active context use the same identifiers and lifecycle.
Identity and multi-tenancy
Give every customer a trusted workspace.
Identity models companies, users, teams, memberships, invitations, sessions, and tenant context as one source-owned product domain.
Inspect the published API contractIdentity domain
Tenant-aware customer model
Product boundary
One company and membership graph behind every product workflow.
01
Company
Tenant boundary and lifecycle
02
Membership
Role, status, and active context
03
Team
Operational grouping inside a company
04
Invitation
Controlled path into the workspace
Source includedPublished contractCustomer-cloud path
- Lifecycle
- Available · v1
- Interfaces
- REST · Connect/gRPC · MCP via Agent Gateway
- AWS path
- Design-partner pilot
- Commercial basis
- Perpetual source license
Product outcome
Your customer model should be a foundation, not a trail of foreign keys.
B2B products need more than login. They need a consistent answer for who belongs to which company, which team they act through, how they were invited, and which tenant context every downstream service should trust.
Product-owned onboarding
Invitation and membership behaviour can match the product instead of a generic authentication screen.
A stable downstream boundary
Authz, Entitlements, Notifications, Audit Log, and product services receive consistent identity context.
01 / Domain capabilities
A complete Identity boundary, not a thin endpoint wrapper.
Each capability belongs to the same tenant-aware service contract and can be adapted in the licensed source.
01
Companies and workspaces
Model B2B tenants, company lifecycle, active workspace context, and users who belong to more than one customer organization.
02
Membership lifecycle
Create, activate, suspend, and remove memberships behind one explicit domain boundary.
03
Invitations and onboarding
Issue, accept, revoke, and expire invitations without scattering onboarding logic across the product.
04
Teams and tenant context
Group members for operational workflows and carry authenticated tenant context into downstream services.
02 / Product workflow
One path from product intent to an enforceable result.
The overview stays business-readable. The documentation and published contract contain field-level detail.
- 01
Create the company
Establish the tenant boundary and the product identifiers other modules will reference.
- 02
Invite the first member
Create a controlled invitation with intended company and membership context.
- 03
Activate membership
Accept the invitation, create the membership, and establish the usable workspace.
- 04
Propagate context
Provide tenant and actor context for authorization, entitlements, notifications, and audits.
03 / Technical depth
Clear operational boundaries for the team that owns it.
Support is 12 months of updates and support. Deployment, updates, and customer-cloud responsibilities are reviewed before purchase.
Invite a company memberHTTP / JSON
POST /identity.v1.MembershipService/InviteMember
Authorization: Bearer $TOKEN
Content-Type: application/json
{
"company_id": "company_72",
"email": "engineer@example.com",
"role": "MEMBER"
}PostgreSQL source of truth
Durable company, user, team, invitation, membership, session, and metadata records.
Domain event boundary
Identity lifecycle events can feed the other modules through the reviewed integration path.
Authorization handoff
Identity supplies actor and tenant context while Authz remains responsible for policy decisions.
04 / Where it fits
Identity supports products with real tenant and commercial complexity.
These are product patterns, not customer case studies or measured outcomes.
Enterprise workspaces
Each customer company manages members, invitations, teams, and workspace context through product-specific rules.
Multi-entity products
One person can belong to several companies and switch active context without duplicating the user identity.
Marketplace roles
A user can participate in buyer and seller organizations while each membership retains its own tenant context.
Ownership model
Own the service without owning every release problem.
The source license, update term, support boundary, and customer-cloud responsibilities remain explicit. Missing domain work can be scoped as a custom module instead of hidden in a roadmap promise.
01
Licensed Go source for the identity domain
02
Published REST and Connect/gRPC contract
03
Customer-controlled identity data and cloud environment
04
Optional custom workflows for missing onboarding requirements
Published API evidence active
Customer-cloud deployment path
No module dependency
Identity architecture review
Put Identity behind a product boundary your team can own.
Bring the tenant model, workflow requirements, cloud target, and any missing module. We will map the service, its dependencies, and the delivery path before discussing a license.
Frequently Asked Questions
Common Questions & Answers
Everything you need to know about integrating and hosting this Launch Rail service.