The DeepCredentials B2B API authenticates every call with a DeepAdmin service-user JWT obtained from the DeepCloud SSO realm. There is no portal-side credential to mint — identity is delegated to DeepCloud's IdP (Keycloak), and the portal verifies tokens at request time.
Every B2B request carries three headers:
| Header | Value |
|---|---|
Authorization | Bearer <access_token> from the DeepCloud SSO token endpoint. |
X-Org-Id | UUID of the organization the call is acting on; the service user must be a member. Required when the service user belongs to more than one organization; if omitted, the call acts on its only organization. |
X-Environment | beta or production. Resources are isolated per environment. |
Start here:
- Service Users — the canonical guide: how to get a partner client and a service user from DeepCloud, exchange credentials for an access token, request scopes, call the API, and the full error reference.
B2B endpoints check the JWT's scope claim. Request scopes explicitly via the scope=… form parameter on the token call; only the scopes your integration uses.
| Scope | Grants access to |
|---|---|
deepcredentials.verify | Create and read OID4VP verification sessions; read verification cases. |
deepcredentials.issue | Create, read and revoke credential offers and invitations, rotate invitation codes, list and inspect issued credentials, suspend / revoke / reactivate. |
deepcredentials.self-service | Read and decide on end-user-initiated self-service requests. |
deepcredentials.verification-cases | Create, update, archive and restore verification cases. Requested separately from deepcredentials.verify. |
A request whose token lacks the endpoint's scope is refused with 403 permission_denied. GET /b2b/v1/health and the credential definition reads (GET /b2b/v1/credential-definitions[/{id}]) need no scope. The per-endpoint mapping is in Service Users → Scopes.
Only request the scopes your integration actually needs. If you only verify identities, scope=deepcredentials.verify is sufficient.