API Reference
The full SenseCrypt REST API — OIDC protocol endpoints, the SAML IdP, SCIM 2.0, and the admin/Management API — generated from the OpenAPI spec, with the auth model and base URL for each surface.
This is the complete SenseCrypt REST API, generated from the service's OpenAPI specification. The pages in this section document every operation — request and response schemas, parameters, and status codes — grouped by surface in the sidebar. This landing page gives you the map: what each surface is for, how you authenticate to it, and how to resolve its base URL.
If you're integrating for the first time, start with the Get Started quickstarts and Concepts — they explain the why and link into the exact operations here.
API surfaces
SenseCrypt exposes four distinct API surfaces. They live on the same host but serve different audiences and use different authentication.
OIDC / OAuth 2.0
The standard OpenID Connect and OAuth 2.0 protocol endpoints your app calls to sign users in: discovery, JWKS, authorize, token, userinfo, PAR, introspection, revocation, and RP-initiated logout. Most OIDC libraries drive these for you after reading the discovery document. See OIDC & OAuth 2.0 for the protocol walkthrough.
SAML 2.0
SenseCrypt acting as a SAML IdP: the IdP metadata, the signing certificate, and the SSO endpoints (Redirect and POST bindings). Your service provider consumes the metadata and posts AuthnRequests. See SAML 2.0.
SCIM 2.0
A SCIM 2.0 endpoint for provisioning and de-provisioning users and groups from your source directory — Users and Groups CRUD, search, bulk, plus the discovery resources (ServiceProviderConfig, ResourceTypes, Schemas). See SCIM 2.0.
Admin / Management API
Everything under /v1/admin/* — the API the admin console is built on and the same API you can call machine-to-machine. It covers applications (OIDC and SAML), users, groups, resource servers, scopes, roles, attribute definitions, signing keys, SCIM tokens, audit and activity logs, branding, uploads, and billing. Browse the admin-* groups in the sidebar; the OIDC apps group is a good starting point.
Authentication by surface
Each surface authenticates differently. Match the credential to the surface you're calling.
| Surface | How you authenticate |
|---|---|
| OIDC / OAuth 2.0 | Standard OAuth client authentication. Confidential clients present their client_id + client_secret at the token endpoint; public clients (SPA/native) use PKCE with no secret. The protocol flow itself is gated by the user's on-device biometric proof. |
| SAML 2.0 | No API credential — trust is established by XML signatures and the exchanged metadata (SenseCrypt signs assertions with the tenant's SAML key; your SP is identified by its metadata). |
| SCIM 2.0 | A bearer token on Authorization: Bearer … — a tenant-scoped machine (client_credentials) access token carrying the scim:read / scim:write capability. See SCIM provisioning. |
| Admin / Management API | Two ways in: an admin session (the cookie the console uses after an operator signs in), or a machine-to-machine bearer token — a client_credentials access token minted for a Management-API app and scoped to the capabilities it was granted. See Machine-to-machine. |
The Management-API bearer is a JWT scoped to a specific tenant and to the capabilities its M2M app holds; a token minted for one tenant is rejected on another. SCIM tokens are the same mechanism, narrowed to the scim:* capabilities.
Base URL and discovery
There is no single global base URL. SenseCrypt is multi-tenant, and every tenant is its own issuer on its own hostname:
https://{slug}.{your-domain}That issuer is the base for all of the tenant's protocol and admin endpoints. Rather than hard-coding paths, resolve them from the tenant's discovery document:
curl https://{slug}.{your-domain}/.well-known/openid-configurationRead authorization_endpoint, token_endpoint, jwks_uri, userinfo_endpoint, and the rest from that document; for SAML, read the tenant's metadata at {issuer}/v1/idp/saml/metadata. The live issuer value is echoed from the host the request arrived on, so it always matches the tenant you called. See Multi-tenancy & issuers.
Note on the operation pages. Paths in the reference are shown relative to a tenant's issuer host (for example
/v1/admin/oidc-apps). Prefix them with your tenant's issuer, and resolve the OIDC/SAML protocol paths from discovery rather than assuming them.
Related
- Get Started — quickstarts that call these endpoints in context.
- Concepts — the protocols and the tokens the API returns.
- Multi-tenancy & issuers — how base URLs and discovery work per tenant.