B2B vs Consumer

Some identity platforms make you choose upfront: "are you B2B or B2C?" We think that's the wrong question -- most real products start one way and grow into the other. Avnology ID exposes a single API surface that handles both.

The unified model

The primitives are the same everywhere:

• Identity -- a human with an email. This is your user.
• Organization -- a container of identities. This is your workspace, tenant, team, or company.
• Membership -- an identity belongs to zero, one, or many organizations.

Consumer apps usually don't create organizations at all -- every user is a solo identity. B2B apps use organizations as the primary unit. Prosumer / SMB apps ("bring this to your team") start solo and add org upgrade flows later. All three use the same API and the same SDK. No migration needed.

Decision matrix

How organizations work

An organization has:

• An owner (the identity that created it, default role owner).
• A member list with roles (owner, admin, member, custom).
• Domains -- if a user signs up with @acme.com and Acme has verified acme.com, we can auto-join them (controlled by the org's registration_mode).
• Optional SSO enforcement -- members of this org must sign in via the org's configured IdP.
• Branding overrides -- logos, primary color, custom domain.

See Organizations API.

Multi-tenancy model

Avnology ID is database-per-org isolated for app data but shared at the identity layer. One identity = one password = one set of passkeys = one MFA. When Jane logs in, she can then switch organizations without re-authenticating.

That's the default because it's what users expect. Strict-isolation ("Jane at Acme and Jane at Initech are entirely different logins") is available for regulated verticals -- set identity_federation_mode=strict at the tenant level. Not the common case.

Common patterns per audience

Pure consumer

• Sign up, sign in, forgot password, MFA, passkeys, profile edit, account deletion.
• One identity = one account.
• Settings live at /account/* in the hosted UI.
• No org chrome anywhere.
• Simpler quickstart: skip the organizations API entirely.

Prosumer / SMB

• Consumer onboarding + an "Create a team" CTA.
• User creates an org via admin.createOrganization (or hosted UI at /organizations/new).
• Invitation flow: admin.inviteMember(orgId, email, role).
• Org-scoped API key for server-side calls.
• Billing: usually per seat; read admin.listMembers(orgId) for the seat count.

B2B SaaS

• User first sees a home-realm discovery step -- enter email, we resolve to their org, show the right sign-in options (password / SSO / passkey).
• Sign-in enforces the org's sso_required flag.
• Admin dashboard uses the gateway's X-Avnology-Org header to scope all list calls to one org.
• Role assignment via Keto tuples (organizations:${orgId}#admin@${identityId}).
• Audit log + SCIM provisioning typically required.

Enterprise

• SSO required via SAML or OIDC. We're the SP.
• SCIM provisioning incoming from Okta / Azure AD. We're the SCIM server (<Domain id="sso"/>/scim/v2/...).
• Conditional access policies (Policy API) gate sign-ins by network / device / risk.
• Audit log streamed to their SIEM via SSF.
• Governance: access requests + review campaigns + SoD.

Mixing audiences in one app

Common: "we're a B2B product but we also have an admin console our employees use." Solve with two OAuth clients:

• Client A (customer-facing): hosted Universal Login, registration_mode=by_invitation_or_domain.
• Client B (internal admin): hosted Universal Login, sso_required=true, Keto tuple organizations:avnology:employee@* gates access.

Both use the same Avnology ID tenant, same identity records. A user who is both a customer admin and an Avnology employee can have two separate orgs they switch between.

What the SDKs do

• The TypeScript + Go + Python SDKs all take an optional organizationId in the constructor that sets the X-Avnology-Org header on every request. Everything scopes automatically.
• The <AvnologyProvider> React component can be wrapped in <OrganizationProvider orgId={...}> to scope React hooks.

Migration cheat sheet

Going from consumer-only to B2B:

1. Keep existing identity records. No data migration.
2. Add an "Upgrade to team" flow that calls admin.createOrganization.
3. Expose the OrganizationSwitcher component.
4. Update your middleware to read X-Avnology-Org.
5. Update billing to scope by org.

Going from B2B to adding consumer accounts:

1. Keep existing org records.
2. Relax org registration -- allow identities with no org membership.
3. Show consumer-only settings at /account/* when no org is selected.

Both migrations are live-safe -- no downtime.