Hybrid-ID · Identity & Access

One place for
identity integration.

Start with accounts and sign-in. Add verification, credentials and privacy capabilities when your experience needs them.

Choose your integration ↓Developer portal ↗OpenAPI contract ↗

Start here

Choose the flow you are building.

  • Existing account access: use the V2 session APIs for approved first-party integrations.
  • Sign-in for your app: integrate through the OpenID Connect provider, with application registration and exact callback URLs.
  • Additional trust: add verification, credentials or privacy proofs only where your workflow needs them.

The endpoint reference below uses the existing V2 schemas, scopes and service ownership.

Accounts & sessions

Where the login routes fit

  • Website login: Hybrid-Chain /login starts GET /api/auth/sso/start, redirects to Hybrid-ID, and establishes its own session after the callback. The compatibility POST /api/auth/login route still uses the V2 session endpoint.
  • Account authority: Identity retains the existing account, credentials and permissions.
  • Identity management: Hybrid-ID’s account workspace brings together profile, password/2FA, sessions, API signing keys, claims, credential lifecycle and optional verification. Each relying application retains its own session and application data.
  • Independent applications: redirect users to Hybrid-ID for authentication. Do not collect Hybrid passwords or request internal browser-session credentials.

Public V2 API basehttps://api.hybrid-chain.com/api/v2

Profile ownership

Identity and application settings have separate owners.

  • Hybrid-ID: edit shared names, profile image, language and region, verified contact details, password and authenticator settings. Manage identity sessions across applications.
  • Hybrid-Chain: read authorized identity details and manage its own base currency, workspace preferences, developer features and application sessions.
  • Enforcement: shared Identity mutations require a session bound to the registered Hybrid-ID portal. A profile-write scope alone does not grant this authority. Existing unbound sessions must sign in again.
  • Verified facts: profile edits never rewrite KYC decisions, verified claims or issued credentials. Corrections follow the verification workflow.

Trust Center ownership

Manage credentials in Hybrid-ID. Verify them across applications.

  • Hybrid-ID Trust Center manages self-asserted claims, selected publication, credential renewal and owner-authorized revocation. Changes require a canonical portal session and fresh authenticator authorization.
  • Hybrid-Chain retains credential views, explorer history and application compliance workflows. Legacy profile-based credential writes and V2 claim writes return 403 HYBRID_ID_MANAGEMENT_REQUIRED; a trust-write scope alone does not grant identity-management authority.
  • Renewal creates a new signed credential and revokes the previous active record. Profile claims remain distinguishable from verification-workflow claims; neither edits nor renewal rewrite an earlier signed document.
  • External agent commerce (devnet) keeps provider connections, shared budgets and commerce evidence in Hybrid-Chain. Core admission is separate from chain enforcement; external payment dispatch remains disabled pending the native execution milestone.
  • Agent identity and audit guide covers canonical owner controls, separately scoped memory credentials, wallet-policy references and owner-approved explorer snapshots. First-party management routes are documented separately from the public V2 contract.
  • Verification guide and public references explain issuer trust, live status, provenance and the supported known-data proof format. OIDC sign-in and developer app-management tokens do not grant claim-writing permissions.

Existing users

From email login to Hybrid-ID.

  • Hybrid-Chain: after a successful email login, users who have not yet used Hybrid-ID can choose to connect before returning to their destination. Their existing account and credentials are retained.
  • Explicit choice: users may continue with email. Choosing Hybrid-ID starts Authorization Code with PKCE and normal consent; an existing provider session can be reused, otherwise provider sign-in is required.
  • Same account: the callback must match the original authenticated Identity and profile, and the original browser session must still be valid. Different accounts are never merged by matching email.
  • Other platforms: authenticate the existing local account first, bind the linking transaction to that session, then validate the Hybrid-ID issuer and subject. Store a unique mapping from issuer + subject to the local account only after both proofs succeed.
  • Conflicts and recovery: if that Hybrid-ID already belongs to another local account, stop and offer a reviewed recovery process. Keep an existing login method until the user has tested Hybrid-ID access. Unlinking should require fresh verification and leave a usable recovery method.

Third-party platforms own their account-linking database and policy. This is an integration pattern, not an automatic cross-platform account-merging API.

Sign in with Hybrid-ID · Live

A familiar sign-in for your app.

The self-hosted provider uses OpenID Connect Authorization Code with PKCE S256. Hybrid-Chain is the first relying application.

The sign-in flow

  1. Register your application. Agree its scopes and exact HTTPS callback URLs with the team.
  2. Redirect to Hybrid-ID. The user signs in with existing credentials and reviews the connection.
  3. Exchange the authorization code. Your server uses its registered client credentials and PKCE verifier.
  4. Establish your app session. Validate the response and recognize the user by issuer and subject.

Integration essentials

  • Validate the response: use a maintained OIDC client to check signature, issuer, audience, state, nonce and PKCE.
  • Request approved scopes: openid profile email. Identity disclosure depends on the registered application and consent.
  • Keep a stable identity: use issuer and subject, never email, to recognize a returning user. Unrelated OIDC sectors receive different subjects.
  • Retain existing accounts: users keep their Hybrid credentials. Other apps receive OIDC credentials, not internal Hybrid browser sessions.

Provider endpoints

These belong to the OIDC provider and are separate from the V2 endpoint catalog.

Canonical issuerhttps://auth.hybrid-id.com

View OIDC discovery ↗
/auth
Start authorization
/token
Exchange an authorization code
/jwks
Retrieve public signing keys
/me
Read approved identity claims
/session/end
End the shared sign-in session

Already using federation? Existing /auth/federation/{provider} routes connect external providers into Hybrid. Hybrid-ID supplies the outward-facing OIDC flow described here.

Discuss an integration ↗

Endpoint reference

Accounts & sign-in

First-party account access, activation, sessions, recovery and authenticators. Public registration is currently invitation-only. Existing federation routes sign users into Hybrid through another provider; they do not provide outward-facing Hybrid-ID SSO.

POSTClose an account/api/v2/account-closure-requests›GETList sessions/api/v2/auth/sessions›POSTCreate session/api/v2/auth/sessions›POSTRevoke session/api/v2/auth/sessions/{session_id}/revocations›POSTVerify bearer token/api/v2/me›POSTDisable authenticator/api/v2/me/authenticator-disablements›POSTBegin authenticator enrollment/api/v2/me/authenticator-enrollments›POSTConfirm authenticator enrollment/api/v2/me/authenticator-enrollments/{enrollment_id}/confirmations›POSTRegister account/api/v2/registrations›GETGet account closure request/api/v2/account-closure-requests/{request_uuid}›POSTCancel account closure request/api/v2/account-closure-requests/{request_uuid}/cancellations›POSTBegin federated authorization/api/v2/auth/federation/{provider}/authorizations›POSTExchange federated authorization/api/v2/auth/federation/{provider}/exchanges›POSTRefresh session/api/v2/auth/session-refreshes›GETGet contact projection/api/v2/me/contact›POSTRequest email change/api/v2/me/contact/email-change-requests›POSTConfirm email change/api/v2/me/contact/email-change-requests/confirm›POSTRequest phone change/api/v2/me/contact/phone-change-requests›POSTConfirm phone change/api/v2/me/contact/phone-change-requests/confirm›GETGet preferences/api/v2/me/preferences›PUTUpdate preferences/api/v2/me/preferences›GETGet core profile/api/v2/me/profile›PATCHUpdate core profile/api/v2/me/profile›POSTActivate account/api/v2/account-activations›GETGet current profile/api/v2/me›PATCHUpdate current profile/api/v2/me›GETList authentication events/api/v2/me/authentication-events›GETGet effective capabilities/api/v2/me/capabilities›PUTChange password/api/v2/me/password›POSTRequest reset link/api/v2/password-reset-requests›POSTReset password/api/v2/password-resets›GETGet tenant brand/api/v2/tenant-brand›

Endpoint reference

Verification & credentials

Optional verification workflows, claims, credentials and attestations. These capabilities are separate from basic sign-in; each endpoint retains its own permissions and availability.

GETGet verification summary/api/v2/me/verification-summary›GETGet status/api/v2/identity/status›GETList verification policies/api/v2/identity/verification/policies›GETList sanctions source posture/api/v2/identity/verification/sanctions/sources›GETList attestations/api/v2/trust/attestations›GETList claims/api/v2/trust/claims›POSTSave claim/api/v2/trust/claims›DELETEDelete claim/api/v2/trust/claims/{claim_uuid}›GETList credentials/api/v2/trust/credentials›POSTStart verification/api/v2/trust/verifications›GETGet verification/api/v2/trust/verifications/{verification_uuid}›

Endpoint reference

Privacy & proofs

Manage privacy preferences and explore identity evidence. Challenge and presentation contracts marked planned are preparation references, not public proof APIs you can call today.

GETGet privacy settings/api/v2/me/privacy›PUTUpdate privacy settings/api/v2/me/privacy›POSTCreate attestation challenge/api/v2/identity/attestations/{credential_uuid}/challenge›POSTCreate attestation presentation/api/v2/identity/attestations/{credential_uuid}/presentation›POSTVerify attestation presentation/api/v2/identity/attestations/{credential_uuid}/verify›GETGet identity/api/v2/explorer/identities/{credential_uuid}›GETGet identity record/api/v2/explorer/identities/{uuid}›GETGet identity issuer/api/v2/explorer/identities/issuer›

For operators

Administration

Restricted identity policy, review and service-credential operations for operators. These are not prerequisites for adding everyday sign-in to an app.

GETGet login policy/api/v2/admin/identity/login-policy›PUTUpdate login policy/api/v2/admin/identity/login-policy›POSTExchange workload assertion/api/v2/auth/workload-token-exchanges›POSTRegister request signing key/api/v2/security/signing-keys›GETGet verification review queue/api/v2/identity/verification/review›POSTUpdate verification review queue/api/v2/identity/verification/review›POSTAssign verification reviewer/api/v2/identity/verification/review/assign›GETVerification evidence/api/v2/identity/verification/review/evidence/{evidence_uuid}›POSTFinalize verification case/api/v2/identity/verification/review/finalize›POSTRequest verification screening/api/v2/identity/verification/review/screen›GETList workload clients/api/v2/admin/identity/workload-clients›POSTRegister workload client/api/v2/admin/identity/workload-clients›POSTRevoke workload client/api/v2/admin/identity/workload-clients/{client_id}/revocations›POSTRotate workload client/api/v2/admin/identity/workload-clients/{client_id}/rotations›GETList request signing keys/api/v2/security/signing-keys›POSTRevoke request signing key/api/v2/security/signing-keys/{key_id}/revocations›POSTCreate step up authorization/api/v2/security/step-up›POSTIssue credential/api/v2/trust/credentials›POSTRevoke credential/api/v2/trust/credentials/{credential_uuid}/revocations›

Availability uses the same recorded production snapshot as the V2 reference (2026-10-02T23:27:55.510Z). It is not a live health check. Confirm the current OpenAPI contract and required permissions before calling.

Existing guides remain available: Trust Center · Identity & Login.