Core concepts

Six terms carry most of the vocabulary in the control plane. Once these are clear, the rest of the docs read without friction. None of them are unique to IntelliAuth — they're standard authentication-platform concepts with our own slug for each.

Organisation

The organisation is the top-level account you sign up for. It owns everything else: tenants, members, audit, plans, billing. One person ("the owner") signs it into existence; other humans join as members.

If you're an IntelliAuth customer running auth for your own product, you have one organisation. If you're an agency or platform running auth for multiple end-customers, you might have several (one per major client, or one and use tenants for separation — both patterns work).

Organisation has two durable identifiers:

Name — friendly label that shows up in emails, audit, invites. Editable.
Slug — the subdomain piece (e.g. cymmetri). Becomes part of every tenant URL — <tenant>-cymmetri.intelliauth.local. Your control plane itself stays at manage.intelliauth.local regardless of slug. Immutable after signup.

Tenant

A tenant is one isolated environment within your organisation — one of your business units, product lines, environments, or regions. Each tenant has its own users, applications, sessions, MFA configuration, branding, and audit log — entirely separate from every other tenant in the same org.

Tenants are your sub-units, not your customers. Common ways to slice them:

By product line. A Cymmetri-style org might have banking, health, and retail tenants — one per product.
By environment. staging and prod for the same product line. Cheap to spin up; useful for keeping test users out of production data.
By region. cymmetri-eu and cymmetri-us if regulatory rules (data residency, separate compliance regimes) force per-region isolation.

The tenant URL pattern is https://<tenant-slug>-<org-slug>.<domain>. So in the Cymmetri org, the banking tenant's URL is https://banking-cymmetri.intelliauth.local. End-users sign in at that URL; that's also what your SDK is configured against.

See Tenants overview for the lifecycle, list view, and per-tenant detail surface.

Member

A member is a human operating your organisation alongside you. Engineers, ops, identity team, customer success — people who run IntelliAuth on behalf of your company. Not the end-users authenticating against your tenants.

Members hold a role: owner (one per org, the signup user), admin (full operational access, can't delete the org or transfer ownership), or viewer (read-only). You invite members by email; they accept and set their own password.

See Members overview for the page and Invite a member for the flow.

Identity

An identity is an end-user authenticating into one of your tenants. Whenever someone signs up to one of your products (built on IntelliAuth), their account lives as an identity inside the tenant that backs that product. One identity per email per tenant; an identity in banking is a different record from an identity in health even if they share an email.

The control plane surfaces a read-only aggregate view of every identity across every active tenant (Identities overview). You can search by email and follow a row through to the user's record inside its tenant for any edit / suspend / delete action.

The terminology to keep straight: members operate your organisation (your platform team); identities authenticate against your tenants (end-users of your products). Two different surfaces, two different audiences.

Plan

A plan is the contract that controls what a tenant (or your whole organisation) can do. It carries quotas (how many users, how many sessions, how many MFA enrollments), feature flags (is SAML federation enabled? custom domains? webhooks?), and rate limits (requests per minute per endpoint).

Every organisation starts on the Free plan. You can upgrade through Billing (when it's wired for your plan). Per-tenant plan overrides exist if your organisation plan allows them.

Audit

Audit is the chronological record of every state-changing action at the org level: provisioning a tenant, suspending one, inviting a member, changing a plan, transferring ownership. The audit page shows this feed; events are filterable by type and tenant.

What audit captures:

Who — the member who took the action, or system for platform-emitted events.
What — a closed-enum event type, plus a payload describing the change.
When — UTC timestamp.

What it doesn't capture: reads (opening a page emits no event), tenant-internal actions (those live in each tenant's own audit log), and infrastructure-level health signals.

See Audit overview for the surface and Audit event reference for the full event catalogue.

Where to go next

You've got the vocabulary. Three suggestions for what to read next:

Console tour — what each sidebar item does, with the dashboard as the hero.
Tenants overview — provision the first tenant and bring up real authentication traffic.
Members overview — bring your team in.