Assetera DocsIntegrating with Assetera
Connect as a distribution partner. The two integration modes, the tenant model, and where the token flow is documented.
Assetera is a B2B2C platform: regulated institutions offer Assetera's tokenized instruments to their own customers through one shared, multi-tenant Marketplace API. You are provisioned as a tenant of that API, and every customer and catalog request is resolved within that tenant context.
Before integrating, read Tenancy & responsibility: it covers how a tenant is resolved and who is responsible for KYC/AML under a reliance vs a tied-agent arrangement.
Choose the customer-onboarding model first
| Model | Identity | Customer due diligence | Start here |
|---|---|---|---|
| Tied agent | Your app signs the customer up with Assetera. The Assetera user ID is the shared subject for KYC, wallet, and API calls. | Assetera performs the agreed flow through MetaKYC embedded in your frontend. | Tied-agent walkthrough |
| DSP with reliance agreement | Existing partner identity, with federation or delegated integration where agreed. | The partner supplies the agreed customer record and evidence under the reliance agreement. | DSP integration |
The legal and compliance model determines the technical route. Do not start by choosing an OAuth grant or copying an SDK snippet.
Choose the delivery pattern
How your customers reach the API depends on whether you bring your own frontend:
| Assetera-hosted UI | Your own frontend | |
|---|---|---|
| Best for | turnkey journeys | partners with an existing product |
| Users sign in via | Assetera-hosted pages | your app → Assetera Identity (redirect) |
| Token handling | Assetera's backend holds tokens server-side | your backend holds tokens server-side (BFF) |
| Also supports | (n/a) | machine-to-machine (client-credentials) for backend-only flows |
In every mode the browser never holds a general Assetera API access token. A BFF keeps OAuth tokens and partner credentials server-side. The browser receives only an opaque session cookie and, when needed, a short-lived token restricted to one SDK or wallet audience.
The end-to-end journey
The exact onboarding steps differ by partnership model. Both routes end in a tenant-scoped customer context that Assetera services can authorize.
The tied-agent walkthrough shows how to wire this journey into your own Next.js app end to end. A tied agent selling a single instrument can settle by bank transfer instead of an on-chain order book: see Off-chain sale.
Next
Tied-agent walkthrough
Build your own frontend: a hands-on Next.js + BFF walkthrough where the keys live server-side and calls are tenant-gated.
DSP integration
Bring existing identities and customer due diligence under a reliance agreement.
Off-chain sale
Sell a single instrument by bank transfer: reference code, IBAN, QR, reconcile, deliver to wallet.
Environment and credentials
Every env var a tied-agent app needs, and how each credential is issued.
Partner onboarding
The path to a live tenant: your identity client, integration mode, reliance/reporting setup, go-live checklist.
Authentication
OIDC token flows, local validation, the tenant claim, and the two grants.
Tenancy & responsibility
Tenants, catalogs, and who owns KYC/AML.
How Assetera works
The platform at a glance: identity, the multi-tenant API, on-chain settlement, and Assetera-run compliance.
Tied-agent walkthrough (Next.js + BFF)
A hands-on walkthrough of building a Next.js app as a tied-agent tenant under Assetera. An OIDC login, a server-side session that holds the tokens, and a tenant-gated proxy to the Marketplace API.