Design partner program
Apply to integrate Abraxas Partner Flow
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, sandbox and production access are operator provisioned, not self serve.
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.
- 1Apply for review →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.
- 2Partner Flow docs →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.
- 3Receipt tester →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.
- 4Test a receipt ID →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.
May be issued after manual approval. Receipts from sandbox policies require allowSandbox in your validator. Not valid for production gates.
Requires approved partner row, active policy, allowlisted callback URLs, and production_usable receipts. No self serve provisioning.
- Read /docs/partner flow, entry URL, callback params, and lifecycle.
- Implement server side receipt verification, GET /api/receipts/{receipt_id}/public before granting access (/docs/partner flow#receipt-verification).
- When operators provision sandbox partner_id, policy_id, and allowlisted return_url, test with the receipt tester (public mirror only).
- 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.
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.
In development
- Consented passwordless partner account creationIn development
Create or recover a partner local account from an Abraxas verification, not deployed yet.
- Pairwise partner identityIn development
Per-partner subject identifiers so partners cannot correlate users across services.
- 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
- User selects Continue with Abraxas Passport — The partner starts Partner Flow with an allowlisted return_url, available today.
- User creates or opens their Passport — zkLogin sign-in and optional identity steps when the policy requires them.
- Abraxas evaluates the partner’s eligibility policy — Policy engine returns approved, denied, or manual_review against required claims.
- User reviews and approves the requested information and actions — Today: Partner Flow consent for verification. Future: separate scopes for account, email, and marketing.
- Partner validates the signed result server side — Fetch and validate GET /api/receipts/{receipt_id}/public before granting access.
- Partner creates or finds its local account and issues its own session — Planned: consented passwordless account bootstrap from verification, partners own sessions today.
- 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.
- Future partner identity must be pairwise so partners cannot correlate users across services.
Illustrative consent layout only, not a live enrollment form. Newsletter is never preselected.
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
Identity-only (POST /api/credentials/verify), wallet trust (GET /api/trust/status), or asset registry (GET /api/verify/registry).
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.
Call our API server-side. Never trust client-side JWT parsing alone. verify signature via our endpoint or published Ed25519 public key.
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
Submit integration intent. Abraxas reviews manually; sandbox credentials may be issued after approval — not instantly.
Submit applicationPartner 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.
After operators provision partner_id, policy_id, and return_url, run npm run partner:conformance.