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.

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.

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

  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.
  • Future partner identity must be pairwise so partners cannot correlate users across services.
Illustrative consent layout (not live)

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

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) {
  // Send the holder through Partner Flow for the method that policy requires.
  // Google sign-in is account access only. Identity or liveness is not the default.
}

// 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 } }
);

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
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

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

Already approved? Read server-side receipt verification docs and use the receipt tester as a public mirror only.

Pitch deck →Cielo E2E checkData room →