Skip to main content

UbID Trust API

UbID Trust API is the developer-facing product domain for integrating identity and trust capabilities into institutional applications. It provides governed contracts for requesting, validating, and coordinating operations across proofing, credentials, presentations, status, access, recovery, and trust metadata.

The API is not a direct window into internal databases or cryptographic keys. It is a controlled boundary that translates external protocol intent into validated domain operations.

Integration philosophy​

A durable trust API should remain stable even when internal technologies change. UbID therefore emphasizes:

  • role-based contracts rather than internal service exposure;
  • explicit schemas and validation;
  • versioned behavior;
  • clear authorization and purpose;
  • idempotent operations where practical;
  • traceable request and decision identifiers;
  • consistent error semantics;
  • separation between preparation, validation, approval, and execution.

Common integration patterns​

Authorized partners may integrate around patterns such as:

  • discover supported credential or verification capabilities;
  • prepare an issuance request;
  • validate data against an approved credential definition;
  • initiate a holder delivery flow;
  • request a credential presentation;
  • submit evidence for proofing or verification;
  • query public issuer, key, status, or protocol metadata;
  • coordinate recovery preparation under policy;
  • retrieve an authorized operation result or evidence reference.

The exact set of operations depends on partner role, deployment scope, and availability status.

Prepare, validate, approve, execute​

Sensitive identity operations should not be exposed as one unconstrained command. The preferred pattern is:

  1. Prepare — assemble the intended operation and required data.
  2. Validate — check schema, identity, policy, trust, and technical conditions.
  3. Approve — obtain the required human or policy authorization.
  4. Execute — perform the authoritative state change or cryptographic operation.

This pattern reduces accidental execution and gives institutions a clear place to apply segregation of duties and evidence requirements.

Error philosophy​

An identity API must fail clearly. Useful errors should distinguish, without exposing sensitive internals:

  • invalid or incomplete input;
  • unauthorized role or scope;
  • unsupported credential or protocol;
  • failed trust or policy validation;
  • stale or consumed transaction state;
  • dependency unavailability;
  • operation pending review;
  • conflict with existing lifecycle state.

Error responses should help an authorized integrator correct a request while avoiding disclosure of anti-abuse rules, infrastructure topology, or other users' data.

Trust metadata and discovery​

Some information is intentionally public or partner-discoverable, such as supported standards, issuer identifiers, public verification keys, credential-type metadata, and service capabilities.

Discovery data must remain curated. Publishing a capability does not grant authorization to invoke it, and public keys must never be accompanied by private material.

Relationship with other products​

UbID Trust API provides an integration boundary across the portfolio:

  • UbID Proof for evidence and assurance interactions;
  • UbID Credential Cloud for issuance lifecycle;
  • UbID Wallet for holder delivery and presentation;
  • UbID Connect for standards and trusted messaging;
  • UbID Recover for guarded recovery coordination;
  • UbID KeyVault through narrow cryptographic services;
  • UbID Pulse for authorized posture and evidence queries.

What this product does not provide publicly​

Public documentation does not provide unrestricted production access, complete customer schemas, tenant credentials, private rate policies, internal service maps, or high-impact administrative operations.

Detailed API specifications are supplied through controlled partner onboarding when the intended role, environment, purpose, and security responsibilities have been approved.

See also Build with UbID, Integration Model, and Partner Onboarding.