Architecture
A control plane for users, roles and grants across many APIs — where every grant names a place and platform capability is explicit.
Your identity provider answers who is calling: authentication, credentials, MFA and SSO stay with it (the identity page covers that boundary). Access Management takes the second question — what may they do, and where. It treats the answer as data: which users hold which roles, at which places, across which APIs. Keeping the concerns apart means access can be granted and revoked without touching how anyone signs in, and adopting Access Management never means migrating credentials. It holds none.
Access Management administers everything that governs access — tenancy structures, users, roles, permissions and grants — and nothing that is business data. Your APIs remain the data plane: each keeps its own schema, storage and deployment lifecycle, and consults the control plane for the authorisation context it then enforces itself. The control plane runs on the same framework it administers: the same request pipeline, the same transactional audit. It is not a special case of the architecture; it is a proof of it.
Access is organised as a tree of access scopes: the named places where a permission can hold — an organisation, the venues inside it, whatever levels the business actually has. The level names are customer data, not platform code. Different APIs can bind at different levels of the same hierarchy, one tenanted per organisation and another per venue, under one administration. Shared authorisation does not require shared application architecture.
The model is small and strict. Six guarantees carry most of its value.
A grant assigns a role to a user at an access scope — always. A grant at an organisation reaches everything beneath it, including venues created later, and the scope it was issued at stays on record, so the original intent remains readable in any review.
There is no wildcard: a grant that reaches every tenant at once cannot be written. An absent or empty scope denies — “nothing” never means “everything”.
Platform-wide capability means administering structure rather than acting inside a tenant. It is a separate, deliberate category of permission, granted like anything else and visible as itself in every review. Every use of it raises an event built for your alerting — surfaced, not buried in a log. And platform administrators see structure, never business data.
Nobody can grant what they do not hold. A user can pass on — or build into a role — only permissions they themselves hold at the target scope, so privilege cannot be escalated through the granting path.
Grants issued, grants revoked, roles changed: every access change produces an audit record naming who acted. Offboarding a tenant is a single audited act — every grant at and beneath its scope revoked at once, not a hunt across systems. And tenant administrators can shape their own roles within their own subtree.
A user can always see their own effective access, even when they have none. Access changes are published as events your security tooling can consume: grants issued and revoked, platform capability used. Oversight never depends on polling the control plane.
APIs ask “where may this user act?” and enforce the answer inside the query itself. Answers are cached with an explicit freshness policy and a deliberately chosen behaviour if the control plane is unreachable. Revocation propagates within the freshness window, with direct cache invalidation for the cases that cannot wait.
Authentication and credential material stay with your identity provider, self-hosted or SaaS, for human and machine users alike. Access Management verifies tokens against it and maps verified identities to its own user records; it stores no secret material of any kind. How the identity seam itself behaves — resolution, caching, migrations — is described on the identity page.
Multiple tenant APIs, and existing APIs connected by contract, can share one control plane while remaining independent systems, each keeping its own schema, rules, storage and deployment lifecycle. Connected APIs declare their permissions to the control plane, so one administration covers every API a customer runs, each binding at the hierarchy level that fits its domain.
The deeper consequence: the isolation boundary and the query boundary are decoupled. With schema-per-tenant or database-per-tenant topologies, a fine-grained tenancy makes every cross-tenant screen a fan-out and merge — so teams pick a coarser boundary defensively, get weaker isolation than they wanted, and bake it into the deployment permanently. Here you tenant at the level your domain means — the venue, because a venue is what the business is. The cross-venue management view then falls out of the authorisation model: one grant at the region, one call spanning exactly the venues it covers. The same mechanism lets an integrator read across every tenant it is entitled to in one call. Tenancy is a modelling decision, and shared authorisation never requires shared application architecture.
The useful evaluation is a conversation held against your tenancy structure, your APIs and your identity provider. This page carries the guarantees. The full architecture document, covering the mechanisms behind them, is available under NDA.