Embed the marketplace in your app
A worked B2B2C example. Your customers buy tokenized securities inside your own app, on your brand, while Assetera holds the licence and runs onboarding and settlement.
Your customers buy tokenized securities without leaving your app. You render the catalog and the confirm button. Assetera holds the investment-services licence, runs onboarding and eligibility, settles the trade, and keeps the audit trail.
This is the pattern for a wallet, a neobank, a broker app, or any product that already has customers and wants a regulated instrument to offer them. It is the same pattern Assetera runs for itself: Assetera is a tenant of its own API.
At a glance
| Who does it | |
|---|---|
| The app your customer opens | you |
| The brand, the layout, the copy | you |
| Sign-in and the customer record | you, federated into Assetera, or Assetera on your behalf |
| Customer due diligence | Assetera, or you under a reliance agreement |
| Eligibility on every action | Assetera |
| The instruments, prices and quotes | Assetera |
| How each instrument settles | the issuer, agreed with Assetera when the instrument is onboarded |
| Settlement, custody and the audit trail | Assetera |
| The investment-services licence | Assetera |
You are one tenant of one shared Marketplace API, with your own catalog, users and audit trail. How a tenant is resolved and isolated is on Tenancy and responsibility.
The journey
- 1Your customer opens your app · Your appAlready signed in to you. Nothing new to learn.
- 2A tenant-scoped session is issued · AsseteraStandard OIDC. Your backend holds the tokens.
- 3Onboarding runs, or your record is relied on · AsseteraEmbedded in your frontend, or supplied under a reliance agreement.
- 4You render the entitled catalog · Your appYour tenant sees only the instruments assigned to it.
- 5Assetera prices it and checks eligibility · AsseteraQuote, limits, appropriateness, trading window.
- 6Your customer confirms · Your appOne confirm in your UI, with your wording.
- 7It settles and the position is theirs · ChainOn chain, measured rather than reported.
You consume the catalog, you do not configure it
How an instrument settles is a property of that instrument, decided by its issuer when it is onboarded. It is not a distributor setting, and it is not a request-time parameter. See List your asset on Assetera for the other side of that decision.
You read it from the catalog: each market carries primaryExecutionKind, and you branch on it. The
values and the fields that travel with each one are on
Primary sale API. Do not infer the rail from
primaryMarket, which only tells you that a primary sale exists.
The consequence is the part that matters for your plan. Your entitled catalog can be mixed, and an instrument whose rail you have not implemented is simply not buyable in your app. Nothing fails loudly: the purchase refuses.
| If your entitled catalog contains | You implement |
|---|---|
| bank-transfer instruments | the off-chain flow: reference code, payment instructions, and delivery once Assetera reconciles the payment |
| Assetera-issued or third-party-venue instruments | the on-chain quote and signed-intent flow. One implementation covers both, because the two on-chain rails are deliberately the same shape |
| both | both, or an entitlement agreed to match what you have built |
That last row is the practical lever. To launch with one flow, agree an entitlement limited to instruments that use it, and widen it later. That is a commercial conversation rather than a code change.
A starter kit is planned, and is not the current answer
Assetera is building a tied-agent starter application that carries these flows so a partner does not implement them from scratch. It is not generally available, and this page describes what you build today. Ask your Assetera contact where it stands before you plan around it.
What you actually build
Four surfaces, and none of them contain a rule.
A backend that holds the tokens. A confidential OIDC client, server-side. The browser gets an opaque session cookie, never a general Marketplace API bearer token. See Authentication.
A list and a detail view. Read the catalog for your tenant and render it. The entitlement is decided by Assetera, so the list is already the list your customers may see.
A confirm step. Ask Assetera for a quote, show it, and submit the customer's confirmation. On the on-chain rails the customer also signs with their wallet. See On-chain primary sale and Off-chain sale.
A place to hand off. Onboarding and the appropriateness assessment run inside an Assetera flow embedded in your frontend. Plan a hand-off point rather than discovering one mid-purchase.
You never compute a price, a fee, a quantity or an eligibility decision. Two implementations of the same rounding is how a one-unit disagreement ships, and on the on-chain rails it makes a purchase revert.
Which model, and who carries what
Tied agent or reliance partner is decided by your licence position, before any code, and the technical route follows from it. The two models and what each customer experiences are on Tied agent or reliance partner. Who is responsible for what under each, and the minimum data that travels, is on Tenancy and responsibility.
What your customer sees
Your app, throughout. The exceptions are the two moments where a regulated flow must be Assetera's own: identity verification and the appropriateness assessment. Both are embedded in your frontend rather than being a redirect to a different-looking site.
Sign-in supports email and password, one-time passcodes and two-factor, passkeys, and single sign-on where it is enabled for your tenant.
Next
Offer the catalog to your customers
The door: the two models, the three delivery patterns, and the five questions for the first call.
Tied-agent walkthrough
The hands-on build: a Next.js app and a backend that keeps the credentials server-side.
List your asset
The other side of the same network: bring an instrument instead of customers.
Partner onboarding
The path to a live tenant: credentials, integration mode, go-live checklist.
Partner onboarding
The technical handover for an Assetera tenant: partnership model, identity, credentials, customer onboarding, and go-live evidence.
Tied-agent walkthrough (Next.js + BFF)
Building a Next.js app as a tied-agent tenant: an OIDC login, a server-side session holding the tokens, and a tenant-gated proxy to the Marketplace API.