Design partner program

Prove reuse across two apps

14-day two-app reuse evaluation for qualified platforms with an existing KYC provider, 2+ gated workflows, and an assigned engineering owner. A relying party is any lender, marketplace, registry, or protocol that accepts an Abraxas credential or Passport state to clear a downstream action without repeating identity verification on the user. Applications are reviewed manually — production access is not automatic.

Partner integrators · start here

From discovery to verified receipt in four steps

For age-gated digital commerce teams embedding Abraxas Partner Flow. Holders verify in the browser; your backend verifies the signed receipt before granting access.

Institutional protocol eligibility (sandbox)

Self-service Launchpad provisioning for organization protocol access. You receive scoped decision receipts, not identity evidence.

  1. 1
    Apply for manual reviewAvailable now

    Submit a design partner application for age gated digital commerce. Abraxas operators review applications manually, there is no self serve production portal and no automatic API-key issuance.

    Apply for review →
  2. 2
    Read the Partner Flow contractAvailable now

    Read the browser-redirect contract, frozen callback parameters, and the server side receipt verification checks your backend must implement.

    Partner Flow docs →
  3. 3
    Use sandbox when provisionedAfter manual approval

    After approval, operators may provision sandbox policies and callback allowlists. Test with the receipt tester using operator provided receipt IDs. Sandbox receipts are not production usable unless your validator explicitly opts in with allowSandbox.

    Receipt tester →
  4. 4
    Verify on your server before accessAvailable now

    On callback, your server fetches GET /api/receipts/{receipt_id}/public, validates signature and policy binding, and only then grants gated access. Use the receipt tester only as a public mirror of that check.

    Test a receipt ID →
Sandbox (operator provisioned test policies)

May be issued after manual approval. Receipts from sandbox policies require allowSandbox in your validator. Not valid for production gates.

Production (operator-provisioned)

Requires approved partner row, active policy, allowlisted callback URLs, and production_usable receipts. No self serve provisioning.

After you apply
  1. Read /docs/partner flow, entry URL, callback params, and lifecycle.
  2. Implement server side receipt verification, GET /api/receipts/{receipt_id}/public before granting access (/docs/partner flow#receipt-verification).
  3. When operators provision sandbox partner_id, policy_id, and allowlisted return_url, test with the receipt tester (public mirror only).
  4. Run npm run partner:conformance after sandbox credentials are issued.

The public receipt tester mirrors GET /api/receipts/{receipt_id}/public, it is not a production access gate. Your server must verify before granting access.

Partner onboarding · honest capability map

One verification. Faster onboarding. Fewer forms.

Abraxas helps users prove eligibility and securely continue into partner experiences without repeatedly exposing sensitive identity information.

Available now

  • Partner FlowAvailable now

    Browser redirect entry, policy evaluation, and privacy-preserving callback parameters.

  • Abraxas PassportAvailable now

    Holder sign-in and optional identity capture when a partner policy requires it.

  • Policy-based eligibility verificationAvailable now

    Partners define required claims; Abraxas returns approved, denied, or manual_review.

  • Signed public receiptsAvailable now

    Server side GET /api/receipts/{receipt_id}/public with signature and trust fields.

  • Privacy-preserving partner callbacksAvailable now

    Frozen callback query parameters contain no PII, partners verify receipts, not URLs alone.

  • Sandbox design partner integrationAvailable now

    Create a sandbox integration after partner sign-in. Upgrade to Production after readiness review.

  • Solana Partner AdapterAvailable now

    Start a policy request, verify the signed receipt on the server, and bind claim access without moving funds.

  • Application-specific subject referencesAvailable now

    Distinct application-facing subject references for new provider-backed institutional individual flows — partners cannot correlate users across services from public receipt surfaces.

In development

  • Consented passwordless partner account creationIn development

    Create or recover a partner local account from an Abraxas verification, not deployed yet.

  • Optional email sharingIn development

    Separate consent scope for contact information, never bundled with eligibility verification.

  • Separate newsletter / marketing consentIn development

    Marketing enrollment is optional and independently consented, never preselected.

  • Returning “Continue with Abraxas” loginIn development

    Faster return visits using verified Passport context, partner sessions remain partner owned.

  • Partner owned sessions and benefitsIn development

    Partners issue their own sessions, preferences, purchases, rewards, and communications.

In development: With explicit user consent, partners will be able to create or recover a local account from an Abraxas verification, request selected contact information, and unlock partner specific benefits without requiring another password.

How it works

  1. User selects Continue with Abraxas Passport — The partner starts Partner Flow with an allowlisted return_url, available today.
  2. User creates or opens their Passport — zkLogin sign-in and optional identity steps when the policy requires them.
  3. Abraxas evaluates the partner’s eligibility policy — Policy engine returns approved, denied, or manual_review against required claims.
  4. User reviews and approves the requested information and actions — Today: Partner Flow consent for verification. Future: separate scopes for account, email, and marketing.
  5. Partner validates the signed result server side — Fetch and validate GET /api/receipts/{receipt_id}/public before granting access.
  6. Partner creates or finds its local account and issues its own session — Planned: consented passwordless account bootstrap from verification, partners own sessions today.
  7. Optional perks or communications are enabled only from independent consent choices — Planned: email and newsletter scopes are separate from eligibility verification.

Privacy and ownership

  • Partners receive only the claims and information the user explicitly authorizes.
  • Abraxas does not send ID photos or date of birth to partners.
  • Eligibility verification is separate from marketing consent.
  • Newsletter enrollment must be optional and separately consented.
  • Each partner owns its local accounts, sessions, preferences, purchases, rewards, and communications.
  • Abraxas must not silently enroll users in third party services.
  • New provider-backed institutional individual flows use application-specific subject references so partners cannot correlate users across services from public receipt surfaces.
Illustrative consent layout (not live)

Illustrative consent layout only, not a live enrollment form. Newsletter is never preselected.

Institutional protocol access (sandbox)

Institutional protocol access and signed receipts. Commerce Partner Flow is a separate path.

  1. Step 1
    Create application

    Create or select your sandbox application in Launchpad.

    Launchpad →
  2. Step 2
    Choose verification

    Select organization protocol access for this integration.

    Verify →
  3. Step 3
    Connect application

    Add callbacks and sandbox credentials.

    Connect →
  4. Step 4
    Test sandbox

    Run tests and complete holder verification.

    Test →
  5. Step 5
    View receipt

    Review the signed receipt and integration activity.

    Workspace →
  6. Step 6
    Request Production

    Submit sandbox evidence for Production authorization.

    Production →
Open integration workspaceVerification SDK docs

After you apply

While Abraxas operators review your application (typically a few business days), start with the Partner Flow contract and server side receipt checks.

  • 1. Read /docs/partner flow, entry URL, callback params, and lifecycle.
  • 2. Implement server side receipt verification, GET /api/receipts/{receipt_id}/public before granting access (/docs/partner flow#receipt-verification).
  • 3. When operators provision sandbox partner_id, policy_id, and allowlisted return_url, test with the receipt tester (public mirror only).
  • 4. Run npm run partner:conformance after sandbox credentials are issued.

Partner Flow guide (start here)

For age-gated digital commerce with a browser redirect: holders complete verification on Abraxas, return to your callback with a receipt_id, and your server verifies GET /api/receipts/{id}/public before granting access.

Onboarding path

1
Choose your trust gate

Identity-only (POST /api/credentials/verify), wallet trust (GET /api/trust/status), or asset registry (GET /api/verify/registry).

2
Test in sandbox

When operators provision sandbox credentials, test Partner Flow receipts with operator-provided IDs. Use the public receipt tester only as a mirror of your server-side check. Registry demos (e.g. /verify/ABX-RE-HOSP-001) are separate artifacts.

3
Implement the gate

Call our API server-side. Never trust client-side JWT parsing alone. verify signature via our endpoint or published Ed25519 public key.

4
Pilot + measure

Run a 30-day pilot with a defined metric: time-to-verify, conversion lift, or cost per manual review eliminated.

Production checklist (after approval)

Production relying-party access requires operator provisioning and passing the same gates Abraxas holds internally. No automatic production key issuance.

  • 1. Read /docs/relying-party-verify — one verify call, proof, independent check
  • 2. Operators may issue production API credentials after approval and conformance — not via a self-serve dashboard
  • 3. Implement server-side POST /api/credentials/verify at your transaction gate
  • 4. Confirm GET /api/proof/{proof_id} returns signature_valid: true
  • 5. First approved production verify logs toward the external RP mainnet gate
1 · Apply

Submit integration intent. Abraxas reviews manually; sandbox credentials may be issued after approval — not instantly.

Submit application
2 · Sandbox test

Partner Flow receipt tester: Paste a receipt_id from your callback and mirror the server side GET /api/receipts/{receipt_id}/public check. /verify · Registry record demo (separate): Public registry showcase only, not a Partner Flow session receipt. Use the receipt tester for callback artifacts. ABX-RE-HOSP-001.

3 · Conformance

After operators provision partner_id, policy_id, and return_url, run npm run partner:conformance.

Conformance command

What you receive

  • Guided two-app sandbox (App A + App B)
  • Starter kit and server verification path
  • Privacy-safe evidence summary when reuse is observed
  • Blocker review — not automatic production approval

Qualification: existing KYC/IDV workflow, 2+ gated applications, engineering owner, sandbox-first evaluation.

What Abraxas needs from you

  • Assigned technical owner for integration
  • A test workflow and policy requirement
  • Feedback on blockers and time-to-value
Start two-app evaluationApply for design partner reviewIntegrate overviewIntegration Studio