Plans, entitlements & usage

What your organization can do in Zynth Auth is expressed as an entitlement set — the features your plan grants and the caps it imposes. One mechanism serves both delivery models: a managed-SaaS plan and a self-hosted licence populate the same schema, so a capability behaves identically in the cloud and on-premise (ADR-0053).

🔒 The rule that matters most: plan and licence state never block authentication. Sign-in, MFA, tokens, sessions, revocation, and audit always work — whatever your plan says, whatever your licence says. A cap can refuse to create something new — another member, agent or OAuth client — but it never takes away what you already have and never stops your people signing in. See When limits are reached.

How your entitlements are resolved

Deterministic precedence — later layers refine earlier ones:

Platform default — the free floor every organization gets.
Plan — your subscription (managed SaaS) or your signed licence (self-host).
Tenant override — a negotiated exception applied by Zynth (e.g. a raised cap).

The result is one set your organization sees everywhere: the API gates on it, and the app gates its UI on the same values, so what you see matches what you can do.

Read them any time: GET /api/v1/entitlements returns your resolved plan, its features, and its caps — see the API reference.

What a plan grants

Only premium capabilities are gated. Core identity is never gateable — password and passwordless sign-in, MFA, passkeys, sessions and revocation, RS256 tokens + JWKS, the OpenID Provider floor, RBAC/ABAC, audit and compliance recording are always included.

Prices and the per-plan feature lists live on the public pricing page: zynthmedia.com/pricing. Each plan's included features list there is generated from the same entitlement definitions the API resolves, so that list tracks what a plan actually grants. The table below is a conceptual summary written by hand — where they disagree, GET /api/v1/entitlements is the source of truth: it returns exactly what your organization holds right now.

Capability	Free	Pro	Enterprise
Core IAM, OpenID Provider, DPoP	✅	✅	✅
Enterprise SSO — OIDC federation	—	✅	✅
Enterprise SSO — SAML	—	—	✅
Directory provisioning (SCIM)	—	✅	✅
MCP tool gateway	—	✅	✅
ISO 27001 ISMS surfaces	—	✅	✅
HIPAA surfaces	—	—	✅
Outbound webhooks	—	✅	✅
Access governance (requests · SoD · certifications)	—	—	✅

A feature your plan doesn't include usually returns 403 with a message naming the feature. One family behaves differently by design: the access-governance surfaces (access requests, separation of duties, certification campaigns — the authz.governance key, enterprise plans) answer 404, exactly as if the capability did not exist — governance surfaces describe your organization's control posture, and a surface you have not bought neither advertises itself nor confirms its shape. The agent approval loop is never plan-gated: agent safety is not a tier. Otherwise a feature outside your plan returns 403 with a message naming the feature — never a silent failure.

Caps and metering

Caps are ceilings on volume, metered per calendar month from the platform's own event record (no extra instrumentation, nothing to install):

Cap	Meaning
`mau`	Monthly active users — distinct people who authenticated this month
`api_calls_monthly`	API requests attributed to your organization this month
`members` · `agents` · `oauth_clients`	Current counts of workforce members, AI agents, registered OAuth clients

Sign-in never stops because a counter moved. Nobody is locked out of their identity provider by a cap: authentication, MFA, sessions and token issuance for existing users are never metered off. mau is a commercial ceiling — you'll see the metric flagged in Plan & Usage, an alert is raised for our team, and we start a conversation.

The rest are enforced at the moment you cross them, because they gate creation rather than access. What you already have keeps working; the next one is refused, with the ceiling named in the message:

Cap	What happens at the ceiling
`api_calls_monthly`	API-key requests are refused with `429` for the rest of the month; see API keys. Interactive sign-in is unaffected.
`members`	New invitations are refused until you free a seat or upgrade — pending invitations count against the seat total; see Team members.
`agents`	Registering a new AI agent is refused (403, "agent limit reached (N)"). Retiring an agent frees its slot; existing agents keep authenticating and acting.
`oauth_clients`	Registering a new OAuth/OIDC client is refused (403, "OAuth client limit reached (N)"). Deleting a client frees its slot; existing clients keep working.

What counts. These three count what is live: a retired agent, a deleted client and a removed member stop counting, and members additionally counts invitations that are still outstanding. Plan & Usage shows the same numbers the refusal uses.

Managing your plan

Admins (tenant:manage) manage everything under Organization → Plan & Usage:

your current plan and what it grants;
usage against each cap, with over-limit clearly marked;
Upgrade — hands off to a PayPal-hosted approval page. Card details go to PayPal, never to Zynth Auth (this is what keeps our PCI scope minimal). During the private beta the Upgrade control is shown disabled with the reason, and the subscribe call answers 403 "Purchases are not open during the private beta" — no plan can be started until pricing is announced;
Cancel — your organization returns to Free at the end of the current term.

Once a subscription activates, your plan changes automatically and your new entitlements apply immediately.

A cancellation stays cancelled. Payment providers retry their notifications, and an older activation notice arriving after your cancellation is ignored rather than applied — so a retry can never put you back on a paid plan you had already left. A genuine re-subscription (including reactivating a suspended one) applies normally.

If your deployment doesn't offer self-serve billing, the page says so plainly — your plan is managed by your administrator or by Zynth directly.

Self-hosted installs

A self-hosted install carries a signed licence file instead of a subscription. It is verified offline — no phone-home, ever, which is what makes air-gapped deployment possible. The licence states your tier, term, and caps, and the app shows its status and renewal date.

As a licence approaches expiry you get a persistent banner. During the grace period after expiry, premium features keep working and new premium configuration freezes. Beyond grace, entitlements fall back to the free floor — premium features stop, rather than becoming read-only — and core identity keeps running untouched at every stage: there is no licence state that stops authenticating. An expired licence is a contract matter, not an outage. See Deployment models.