Trustware: Widget, Headless API, or Host-Wallet Bridge, Which Integration Style Fits Your App?

Q: Do all three integration styles support the same chains and wallets?

Yes, they share the same underlying routing and wallet layer; the difference is UI and wallet-management ownership.

Q: Can I start with the widget and move to headless later?

Yes, since configuration and routing are shared, switching is a reconfiguration rather than a rebuild.

Q: Does the host-wallet bridge mode support every wallet adapter?

Confirm current supported wallet adapter list directly before publishing.

Q: How much can the widget actually be customized visually?

Theme and message config cover color, radius, and copy; deeper structural changes need the headless API.

Q: Is the headless API harder to maintain long-term?

It requires building and maintaining your own UI, more ongoing work in exchange for full control.

Q: Which style is most common for new integrations?

Confirm current distribution of integration styles among live integrations directly before publishing.

TL;DR: All three Trustware integration styles share the same routing and configuration underneath; what differs is how much UI and wallet-management responsibility you hand to the SDK versus keep in your own app. The right choice depends on whether you already manage wallet state, how much UI control you need, and how much of the deposit flow you want to own directly.

What are the three integration styles?

A prebuilt React widget handles the full deposit flow, wallet selection through success or error, with no custom UI required. A provider plus host-managed wallet bridge lets an app that already manages wallet state, through Wagmi or another adapter, reuse that state instead of ceding wallet discovery to the SDK. A headless core API exposes the same routing functions directly for a fully custom interface.

A framework for choosing

Axis 1, do you already manage wallet connection state?

If your app has no existing wallet management, the widget's autoDetectProvider handles wallet discovery for you. If you already manage a connected wallet through Wagmi or a similar library, the host-wallet bridge mode lets you pass that wallet in directly, disabling the SDK's own detection so it doesn't compete with logic you already have.

Axis 2, how much UI control do you need?

The widget's UI can be themed and its copy overridden through theme and messages config, which covers most branding needs without custom component work. If your product requires a UI that doesn't fit the widget's step model at all, the headless core API lets you build every screen yourself around buildRoute, getQuote, and runTopUp.

Axis 3, how much of the flow do you want to own directly?

The widget owns wallet selection, amount input, confirmation, and status display entirely. The headless API hands all of that back to your app, in exchange for full control over every interaction. The host-wallet bridge sits in between, using the widget's UI while keeping wallet ownership with your app.

The Trustware view, this isn't a maturity ladder, it's a fit question

Teams sometimes treat the headless API as the "more advanced" option and the widget as a placeholder to graduate from. In practice, plenty of production apps stay on the widget indefinitely because it fits their UI and wallet needs, while some teams start headless because their product's UI never fit a widget's step-by-step model in the first place.

A contrarian take, starting with the widget doesn't lock you into it

Because all three styles share the same underlying configuration and routing, moving from the widget to a host-wallet bridge or headless integration later is a matter of changing how you consume that layer, not migrating to different infrastructure entirely.

What to check before choosing an integration style

Does your app already manage wallet connection, or does it need that handled for you?
Can your branding and copy needs be met through theme and message overrides, or do you need a custom UI entirely?
Do you want to own the deposit flow's UI directly, or is a prebuilt flow acceptable?
Does your team have the bandwidth to build a custom interface around the headless API, versus using a prebuilt one?
Would switching integration styles later require significant rework, or just reconfiguration?

See the Trustware docs for current integration style details.

FAQ

Do all three integration styles support the same chains and wallets?

Yes, they sit on the same underlying routing and wallet layer; the difference is in UI and wallet-management ownership, not underlying capability.

Can I start with the widget and move to headless later?

Since configuration and routing are shared across all three styles, switching is a matter of how you consume that layer rather than rebuilding routing logic from scratch.

Does the host-wallet bridge mode support every wallet adapter?

{{CITE: confirm current supported wallet adapter list for host-wallet bridge mode before publishing}}

How much can the widget actually be customized visually?

Theme and message config fields cover color, radius, and copy customization; deeper structural changes to the step flow would require the headless API instead.

Is the headless API harder to maintain long-term?

It requires building and maintaining your own UI around the routing functions, which is more ongoing work than using the prebuilt widget, in exchange for full UI control.

Which style is most common for new integrations?

{{CITE: confirm current distribution of integration styles among live integrations before publishing}}

How to decide

Choose the widget if you want the fastest path to a working, branded flow. Choose the host-wallet bridge if you already manage wallet state and want the widget's UI on top of it. Choose the headless API if your product's UI genuinely doesn't fit a prebuilt step flow.

See trustware.io for current integration options.