Trustware: What "15-Minute SDK Integration" Actually Requires From Your Team
TL;DR: A fast SDK integration claim is only useful if you know exactly what it covers. For Trustware, the core setup is genuinely small: install the package, define a config object with an API key and a destination chain/token, wrap your app in a provider, and drop in the widget. What takes longer is everything downstream of that, theming, custom amount guardrails, and wiring a host-managed wallet if you already have one.
What does the core integration actually involve?
The minimum integration is a package install, a config object, a provider, and a widget component, using React and TypeScript with no backend changes required for the prebuilt-widget path.
What "15 minutes" actually covers
Step 1, install the package
```bash
npm install @trustware/sdk
```
Supports React 18.2+ and 19 as peer dependencies.
Step 2, define your config
A minimal config needs an API key and a routes object specifying toChain and toToken, the destination your app wants to receive regardless of what the user holds. Optional fields, defaultSlippage, routeRefreshMs, theme, and message overrides, can be added but aren't required to get a working integration running.
Step 3, mount the provider and widget
Wrap your app in TrustwareProvider with your config, then render TrustwareWidget inside it. With autoDetectProvider enabled, wallet discovery is handled by the SDK, no separate wallet integration code required for this path.
Step 4, confirm the flow end to end
The widget's built-in flow, Home through Select Token, Confirm Deposit, Processing, and Success or Error, should now be testable without any additional custom code. This is the point where the "15-minute" claim is accurate: a working, testable deposit flow.
What takes longer than 15 minutes
Wiring an existing wallet connection
If your app already manages wallet state through Wagmi or another adapter, integrating that instead of using Trustware's auto-detection means writing the bridge code, passing a wallet instance into the provider and disabling auto-detection, which is straightforward but is additional work beyond the core setup.
Theming and message customization
Matching the widget's visual design to your app and rewriting default copy through the theme and messages config fields is usually a design and content pass, not a blocker to a working integration, but it's real time beyond the initial setup.
Amount guardrails and custom validation
Configuring fixed amounts or minimum/maximum output constraints for specific use cases, like a payment link with a set price, takes additional configuration and testing beyond the default any-amount flow.
Retry and error handling for production traffic
The default retry configuration works out of the box, but tuning it, and building app-specific handling around a typed RateLimitError or other error events, is production-hardening work that a proof of concept typically skips.
The Trustware view, the honest claim is "a working flow in 15 minutes," not "a finished integration"
The 15-minute framing is accurate for what it actually describes: getting from zero to a testable deposit flow. Treating it as a claim about a fully production-ready, custom-themed, hardened integration oversells what any SDK's quick start is meant to cover.
A contrarian take, the fastest path to production isn't always starting with the widget
Teams that already manage wallet state and need tight control over the deposit UI sometimes spend more total time forcing the prebuilt widget to fit than they would starting with the headless core API and building their own interface around buildRoute, getQuote, and runTopUp directly.
What to plan for beyond the initial setup
- Do you need to wire an existing wallet connection, or is auto-detection sufficient?
- How much visual and copy customization does your brand actually require?
- Do you need fixed amounts or min/max guardrails for a specific use case?
- Have you tuned retry behavior and built handling for the errors your app will actually see in production?
- Would the headless API better fit your architecture than the prebuilt widget?
See the Trustware docs and @trustware/sdk on npm for current setup details.
FAQ
Is the 15-minute integration claim accurate?
For the core setup, install, config, provider, widget, yes, that's genuinely a small amount of code. It describes reaching a working, testable flow, not a fully themed and hardened production integration.
Do I need a backend change to use the prebuilt widget?
No backend change is required for the widget path; configuration happens client-side through the provider.
What if I already manage wallet connections myself?
Pass your existing wallet client into the provider and disable auto-detection, so the SDK doesn't take over wallet discovery your app already handles.
Can I skip the widget entirely and build my own UI?
Yes, the headless core API exposes buildRoute, getQuote, and runTopUp directly for a fully custom interface.
Does the SDK require a specific React version?
It supports React 18.2 and above, including React 19, as peer dependencies.
What's the realistic timeline for a production-ready integration, not just a working flow?
{{CITE: confirm typical timeline including theming, wallet-bridge wiring, and error-handling hardening before publishing}}
How to decide your integration path
If you want the fastest path to a working flow, the prebuilt widget with auto-detection gets there in the time the quick start describes. If you have existing wallet infrastructure or need tight UI control, budget additional time for a host-wallet bridge or headless integration, and expect that time to go toward wiring and hardening, not toward the core routing setup itself.
See trustware.io for current integration options.