PASSID
PASSID API Docs Partner-ready reference
Overview API Reference Security Test the verify flow
Verifier API Reference

Receive a token. Verify signed claims. Keep the audit trail.

This reference starts with the core institution handoff: submit a PASSID token, verify signed claim summaries, check freshness and revocation, receive audit metadata, and keep raw financial statements and transaction feeds out of the verifier response.

Token Applicant shares a scoped PASSID token
Verifier response Signed claims, lifecycle checks, and audit metadata
No raw feed No financial statements or transaction feeds in the response
Verifier response
Token validity, issuer signature, signed claims, freshness, revocation status, and audit identifiers.
Privacy boundary
Verifier examples show scoped claim summaries and metadata, not raw transaction data.
Verifier moment
Institution receives a token, verifies signed claims, gets audit metadata, and keeps the final decision.
API essentials

Create share token, verify token, return claims.

PASSID Verify is a credential verification flow. The user wallet creates a scoped share token, the institution verifies it with an institution key, and PASSID returns structured claims plus freshness, revocation, and audit metadata. PASSID is not a credit bureau, lender, bank, public public scoring product, or decision workflow.

Authentication Use X-Institution-Key

Verification endpoints require X-Institution-Key: <institution_key>. Keep live keys on your server and never expose secrets in frontend code.

POST /api/v1/bridge/share/create Create share token

The user wallet creates a scoped PASSID token for a verifier. The token should represent only the scoped claims the user consented to share.

POST /api/v1/bridge/verify Verify token

The institution submits the token and receives signed claim summaries, token status, freshness, revocation, and audit context.

GET /api/v1/bridge/verify/{token} Fetch verification

Retrieve the verification record for a token when your workflow needs status, metadata, or audit trail review after the initial call.

POST /api/v1/bridge/share/revoke Revoke share

The user can revoke a shared token. Verifiers should check revocation state before relying on returned claims.

GET /api/v1/bridge/share/user/{userId} User share history

Wallet-side history shows which tokens exist, where they were shared, and whether access remains active or revoked.

Claims schema Structured credential claims

Expected claim fields include identity verification, income verification, savings consistency, payment reliability, sanctions status, fraud risk, and freshness metadata.

Error codes Handle token lifecycle states

Plan for invalid tokens, expired tokens, revoked shares, missing institution keys, access-gated live mode, malformed requests, and unavailable sandbox fixtures.

Sandbox / live mode Test safely before production

Sandbox tokens may return synthetic demo claims. Live verification should be gated by workspace access, plan controls, and partner approval.

Try the verify flow

Try the verify flow

PASSID is easiest to understand as one clean handoff. The user creates a scoped share token, the institution sends that token to /api/v1/bridge/verify, PASSID returns signed claim summaries, freshness, revocation state, and audit metadata. The institution keeps the final onboarding, risk, or compliance decision.

Create share
Verify token
Return claims
Institution decides
Step 1 User creates a PASSID share token

The wallet creates a scoped share the applicant can hand to a verifier without exposing raw financial statements or repeated document uploads.

Step 2 Institution sends token to /api/v1/bridge/verify

The bank, lender, or platform submits the received token with its institution key so the verification is attributed correctly.

Step 3 PASSID returns signed claims and audit context

The response includes claim summaries, issuer signature status, revocation status, freshness, verification timestamp, and audit identifiers.

Step 4 Institution makes the decision

PASSID does not approve, deny, lend, or underwrite. The institution uses the verified claims in its own onboarding, compliance, or risk workflow.

Sample request Send the token to PASSID verify
POST /api/v1/bridge/verify
{
  "token": "PASSID-EXAMPLE-TOKEN"
}
Sample response Signed claims and audit metadata returned
200 Response
{
  "success": true,
  "data": {
    "credential_valid": true,
    "token": "PASSID-EXAMPLE-TOKEN",
    "audit_id": "vrf_82a4c9",
    "verifiedAt": "2026-04-09T14:12:00Z",
    "signature_valid": true,
    "revocation_status": "clear",
    "claims": {
      "identity_verified": true,
      "income_verified": true,
      "income_band": "$3,000-4,000/mo",
      "sanctions_screening_clear": true,
      "payment_behavior_verified": true,
      "savings_behavior_verified": true,
      "identity_and_fraud_checks_passed": true,
      "data_window_days": 180
    },
    "raw_transactions_included": false
  }
}
identity_verified = identity confirmed
sanctions_screening_clear = OFAC · EU · UN
PASSID returns verified credential signals. Final decisioning remains with the institution.
Rendered inside PASSID, backed by the current OpenAPI source of truth. The page below is generated from the active PASSID API contract and rendered in-app. It is designed for partner engineers, solution architects, and risk teams reviewing endpoint behavior before a pilot or production launch.
Embedded spec loaded in-app
PASSID Reference Endpoints, auth, request examples, response examples, and schemas rendered with Redoc.
/docs mounted route
No raw spec download link
Mobile-friendly layout
Loading PASSID API reference...