Integrations

The reusable verification primitive

Public beta · design partner applications reviewed manually. Submit integration intent below — sandbox policies and callback allowlists are operator-provisioned after approval, not self-serve.

Apply once at this form. Abraxas operators review applications manually. There is no self-serve production portal or automatic API-key issuance.

Apply for manual review Partner Flow docs Receipt verification

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
Manual review, operator-provisioned sandbox policies, callback allowlists, and conformance tooling.

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 (not live)

Verify my eligibilityCreate or sign in to my partner accountShare my email with this partnerSubscribe me to this partner’s newsletter

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

Partner Flow docs Apply for sandbox Passwordless onboarding plan →

Relying party program

The network-effect milestone: an unaffiliated lender, marketplace, or protocol checks Abraxas credentials in production. Partners configure eligibility rules. Abraxas returns approved / denied / manual review with consent receipts and audit references.

Relying party onboarding →Outreach templates

Policy Engine

Partners define required claims (identity, screening, wallet binding, accreditation) with assurance levels and max age. The engine evaluates live claim status. not a static profile. and logs every decision.

Seeded policies: abraxas-core-v1, abraxas-booking-v1, abraxas-rwa-us-v1
POST /api/v1/policies/evaluate. direct evaluation
GET /api/v1/decisions/{id}/status. re-check before settlement

Trust Registry

A credential is only valuable if the verifier trusts the issuer. Abraxas maintains which issuers may sign which claim types, with assurance tiers, jurisdictions, and audit status.

GET /api/trust/registry. issuers + W3C schema identifiers
Veriff · Abraxas Network · Manual Review · Screening (partner-gated)
Issuer suspension and schema versioning

View registry JSON →

Quick integration

Example server-side pattern only. API credentials are operator-provisioned after manual approval — not self-serve.

// 1) Check if user meets your policy before an action
const check = await fetch("https://abraxasworld.xyz/api/verification/check-level", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ sui_address: walletAddress, action: "book_asset" }),
});
const level = await check.json();
if (level.needsDeepVerification) {
  // Prompt ID check — user completes Veriff once
}

// 2) Partner flow: create request → user consents → get decision
const req = await fetch("https://abraxasworld.xyz/api/v1/verification-requests", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "X-API-Key": process.env.ABRAXAS_PARTNER_API_KEY,
  },
  body: JSON.stringify({
    policy_id: "abraxas-rwa-us-v1",
    requested_action: "subscribe_to_offering",
  }),
});
const { request_id, consent_url } = await req.json();

// 3) Re-check decision before settlement
const status = await fetch(
  `https://abraxasworld.xyz/api/v1/decisions/${decisionId}/status`,
  { headers: { "X-API-Key": process.env.ABRAXAS_PARTNER_API_KEY } }
);

Partner Flow docs Receipt verification Architecture

Integration registry (3 pilot surfaces)

Abraxas AppLiveFirst-party

Cielo booking, passport, and asset terminal — internal dogfood of the full loop.

GET /api/trust/status

AIL Public APILiveDeveloper

Trust status, credential verify, passport read, intent proofs.

GET /api/trust/status · POST /api/credentials/verify

Cielo Stablecoin CheckoutLiveHospitality RWA

Live USDC payment rail for verified short-term rental on Sui mainnet.

GET /api/cielo/config

External RWA MarketplaceRecruitingDesign partner slot

Accept Abraxas Passport for investor eligibility without re-KYC.

POST /api/credentials/verify

DeFi / Private Credit ProtocolRecruitingDesign partner slot

Collateral verification + identity tier for borrow against verified RWAs.

GET /api/sui/passport

Music Royalty PlatformPilotPipeline

Catalog ownership attestation via Abraxas music audit intake.

/music-audit

Pilot page →

Good Trouble CannabisPilotRegulated retail (pilot)

Kansas City organic cultivator (est. 2022). Passport retail eligibility + batch provenance fixtures for cannabis SDK.

POST /api/credentials/verify · GET /api/good-trouble/batch

Pilot page →Website ↗

Become a design partner

For age-gated digital commerce teams integrating Partner Flow. We prioritize partners with a clear conversion metric and a defined eligibility gate.

What happens next: manual review (typically within a few business days). No self-serve production access or automatic API-key issuance. Sandbox credentials are operator-provisioned after approval.

Clear workflow where reusable identity or asset proof reduces friction
Willingness to pilot with real users (even small volume)
Defined success metric (conversion, time-to-verify, cost per check)
Permission to name publicly after pilot success

Pitch deck →Cielo E2E check Data room →