Self-serve Admin Portal
A capability-scoped, time-limited link a tenant's own IT admin can follow to configure SAML and/or SCIM directly — no Qeet ID account, no console login.
Configuring SSO usually means either handing your IT admin a seat in your own admin console, or your engineers relaying certificate/metadata values back and forth by email. Qeet ID's Admin Portal is a third option, matching WorkOS's category-leading pattern: generate a link, hand it to whoever owns the identity provider on the customer's side, and they configure it themselves — directly, on your brand, without ever creating a Qeet ID account.
What makes the link safe to hand out
The link carries no identity of its own — only a capability set (
saml, scim, or both) and an expiry. Possession of
the raw token is the sole credential, hashed at rest exactly like an invite or
magic-link token. It isn't single-use — the IT admin can return to it any
number of times until it expires or you revoke it — but every action it
authorizes is scoped to only what you granted.
Generate a link
/v1/tenants/{tenantID}/admin-portal/linksGenerate an admin portal link{
"capabilities": ["saml", "scim"],
"ttl_seconds": 86400
}ttl_seconds is clamped to 15 minutes–7 days (default 24h). The response's token /
url are shown exactly once — there's no re-read endpoint, so copy the link before
navigating away.
/v1/tenants/{tenantID}/admin-portal/linksList links (metadata only)/v1/tenants/{tenantID}/admin-portal/links/{id}Revoke a linkAlso in the console: Developer → Connections has a Self-serve Admin Portal card that generates, lists, and revokes links without touching the API directly.
What the IT admin sees
The link points at the hosted login app — {loginBaseURL}/admin-portal/{token} — a
standalone, on-brand page (your logo, your colors, via the same branding pipeline as
hosted login) with a tab per granted capability:
- SAML tab — list existing connections, add a new one (entity ID, SSO URL, signing certificate, attribute mappings), run the same offline preflight test the admin console uses, or delete a connection.
- SCIM tab — see whether a token is set and how many users are provisioned, roll a new bearer token (shown once), or disable provisioning entirely.
Every write the portal makes calls the exact same saml.Service / scim.Service code
path as the authenticated admin console — there's no separate, thinner implementation
to keep in sync.
Deliberately not exposed
The portal never lists SCIM-provisioned users (that's PII an anonymous link-holder shouldn't see) and never touches the SAML IdP-side registry (that's Qeet-Group-configured, not a tenant concern) — only the SP-side connection and the SCIM token itself.
Under the hood
The public, token-gated endpoints an IT admin's browser calls mirror the admin console's own SAML/SCIM routes one-for-one, just resolved by the token instead of a tenant-scoped JWT:
/v1/admin-portal/{token}/contextPortal context (tenant name, capabilities, branding)/v1/admin-portal/{token}/samlList connections/v1/admin-portal/{token}/samlCreate a connection/v1/admin-portal/{token}/scim/tokenRotate the SCIM tokenA request against a capability the link doesn't grant — SCIM on a SAML-only link, say — gets a plain 403, not a stack trace or a silent no-op.