How to Choose a Crypto Swap Integration: Widget vs SDK vs API
Pick the wrong swap surface and you either paste a foreign-looking box, or you spend weeks on HTTP that a widget would have covered. For a crypto swap widget vs API decision, start from the job. Choose a Widget if you need a ready swap screen this week. Choose an SDK if your wallet already connects and signs. Choose the raw API if there is no UI, or the library hides the endpoint. You leave with a table, a checklist, and a partner ID on the first quote.
Summary: Match the job to the surface, then ship: Widget for a ready swap UI this week, SDK when you already connect a wallet, raw API for a bot or a missing method. Create a Partner Portal key, stamp every request with a partner ID, and smoke-test a quote plus a failed route before you call it live.
A swap aggregator is a router. It looks for a path across DEX pools (on-chain markets), centralized exchangers, and private liquidity, then asks the user to sign. YiFi does not hold client funds.
The surface is how your product talks to the router. It is not how you get paid. Read the crypto swap API fee models guide after you lock Widget, SDK, or API. Do not mix the two choices.
Start from the job: choose UI this week, own quotes, or skip UI
Write the job in one sentence before you open docs. A Widget is a ready-made swap screen you drop into a page. An SDK (software development kit) is a helper library: they quote and build the transaction, you draw the buttons. An API is a door for HTTP: your code sends a request and gets JSON back. Do not start from “we need full control.” Start from what ships this week.
Check the chains and tokens your users actually hold. Confirm Ethereum, Arbitrum, BSC, and Base if that is your traffic. Do not invent a live non-EVM list.
LI.FI decision tables send no-UI products to the API, custom UI to the SDK, and a ready screen to the Widget. Use that split. Do not copy another vendor’s minutes as a YiFi clock.
Workflow: Job (UI this week vs own shell vs no UI) → pick Widget / SDK / API → Partner Portal key → attach partner ID → smoke-test quote + sign → confirm volume in the dashboard.
Do this: pick one primary surface. A hybrid is fine later (SDK by default, HTTP where the library is silent). Do not begin with raw API “for control” if you have nothing custom to protect.
Compare Widget vs SDK vs API before you write code
Use this table as a gate. Time-to-first-swap is YiFi’s fee-models FAQ range, not a universal SLA. If two columns both look tempting, the “Best job” row decides.
| Criterion | Widget | SDK | Raw API |
|---|---|---|---|
| What you ship | Provider swap UI (iframe or JS drop-in). | Your UI plus their quotes and tx build. | Your UI or no UI. You parse JSON. |
| Who connects the wallet | Widget wallets, or passthrough if offered. | You wire the signer. | You, on the client or the bot. |
| Best job | Site, token page, MVP this week. | Native wallet or dApp with connect already. | Bot, backend, missing SDK method. |
| YiFi time to first swap | Often within days (fee-models FAQ). | Typically one to a few weeks. | Longest of the three. |
| Attribution | Partner ID in the embed. | Partner ID in SDK config. | Partner ID on POST /v1/swap. |
Verdict: Choose a Widget for a marketing site, docs, token page, or a team with no wallet stack. Choose an SDK for a wallet or dApp that already connects. Choose the raw API for a bot, a server, or an endpoint the library hides. Default: SDK plus targeted HTTP. Do not open with raw API because it feels more “serious.”
One YiFi integration can sit in front of homepage sources (LI.FI, Rango Exchange, 0x, Quickex, ChangeNOW). Do not wire each separately unless you must.
Use a Widget when you need a swap UI this week
A Widget is the fastest path and the least UI control. You embed a ready screen. Users pick tokens, read a quote, and sign. Do this when swap is a feature on a site, not the whole product chrome.
Watch how the wallet connects. Some widgets bring their own connect flow. Others keep the host wallet. Jupiter’s embed guide calls that wallet passthrough. If your widget offers a similar switch, turn it on. Do not make the user connect twice.
A Widget is still not “set and forget” for money. SwapKit’s widget intro says affiliate fees do not attach themselves. Same idea here: put the partner ID in the embed. Do not ship without that stamp. Off-chain legs can still label, delay, freeze, or reject.
YiFi’s fee-models FAQ says a widget is often deployable within days. Treat other vendors’ minute-counts as their marketing. Do this: Widget for a landing or token page when the provider UI is enough. Do not force a Widget into a wallet that already has its own swap screen.
Build on the SDK when you already connect wallets
An SDK is the default for a real wallet or dApp. You keep layout and connect. They return an indicative quote (a preview price, not a locked deal) and build the transaction. You still wire the signer. Check connect, network switch, and broadcast. Do not assume an import means a swap can complete.
Quotes can differ from the final fill. Slippage, a missing route, or a bridge delay can change the outcome. Show the quote as indicative. Do not display a preview as a guarantee.
Do this: SDK when connect and sign already work, and you want your own shell. Attach the partner ID in SDK config. Do not hide failed routes. Surface “no route” instead of retrying forever.
Choose the raw API for bots, backends, and missing methods
Raw API means you speak HTTP: quote, parse, sign, poll. Use it for a Telegram bot, a server, or a stack with no official SDK.
This path is normal. The 0x Swap API quickstart is REST-first: price, then quote, then an executable transaction. Use raw HTTP when the SDK is silent. Do not use it as a status symbol.
On YiFi: Partner Portal → POST /v1/swap with the partner ID → quote and route → user signs → GET /v1/transactions/{transaction_id}. Cookie tricks do not survive a bot. Put the partner ID on the request.
Do this: raw API for no-UI jobs and missing SDK methods. Keep SDK as the default elsewhere. Do not build a second aggregator.
Run this checklist: chains, fee model, keys, then smoke-test
Make sure the surface choice is done before you touch keys. Then run the list in order.
- Write the job in one sentence: UI this week, own shell, or no UI.
- Check real user chains and tokens against aggregator coverage, not a marketing chain count.
- Keep execution non-custodial: the user signs, you never hold the balance mid-swap.
- Pick Widget, SDK, or raw API. Hybrid is SDK plus HTTP only where the library is silent.
- Open Partner Portal, pick company (up to 5 keys and a team) or individual (one key plus a referral code), and create the first key.
- Attach the partner ID on every request: embed parameter on a Widget, config on an SDK, POST /v1/swap on the API.
- Read API Terms. Commercial use, Partner API, or revenue-share may need a written Partner Agreement.
- Smoke-test an indicative quote, a signature, a KYC label (an ID check) on an off-chain route, and a failed or no-route case.
- Confirm volume and commission in the Partner Portal dashboard. Do not retell markup vs revenue-share here.
Keys live in the Partner Portal. Company vs individual is in the YiFi Partner Portal launch. Create the live account at the Partner Portal. Do not put a secret key in a public frontend unless docs say it is public.
API Terms cover APIs, SDKs, widgets, and data feeds. Commercial or revenue-share use may need a Partner Agreement. Check YiFi API Terms before you sell the integration. Do not guess.
YiFi itself does not run KYC or AML on users. Off-chain providers still may, and the UI can show a KYC label. Do not claim KYC never applies because you shipped a Widget. FeeSplitter on Earn/Zap is a different circuit. Do not mix those claim steps with Swap dashboard volume.
What next: pick the surface, create the key, stamp the partner ID, and run the four smoke cases. Then read YiFi Swap API docs for the endpoints you will call. Avoid a second provider until chains and the fee model still match.
Frequently asked questions
Which path is fastest for a crypto swap widget vs API?
Start with a Widget if you accept the provider UI. YiFi’s fee-models FAQ says that path is often deployable within days. Do not promise a five-minute YiFi install.
Do I need a Partner Agreement to integrate?
Open the API Terms and check your use. Commercial use, Partner API access, or revenue-share may require a written Partner Agreement. Do not assume a free-tier key covers a paid embed.
Where do API keys live?
Create them in the Partner Portal. Company: up to 5 keys and a team. Individual: one key plus a referral code. Keep secrets off public pages unless docs say otherwise.
We already have wallet connect. Widget or SDK?
Choose the SDK, or a Widget with wallet passthrough. Do not force a second connect modal. If the widget cannot reuse your adapter, skip it and keep the SDK.
Can a Telegram bot use a Widget?
No. Use the raw API, or a server-side SDK if one exists for your language. Put the partner ID on the request. Do not rely on cookies. Bots have no page to embed.
Can we start on a Widget and move to API later?
Yes. Widget to launch, API when swap is core, is a common path. Keep the same aggregator when you switch surfaces. Re-check chains and the fee model before you change providers.
Does a Widget mean YiFi never asks for KYC?
No. YiFi does not run user KYC itself. An off-chain provider on the route can still label, delay, freeze, or reject. Read the route. Do not copy anonymity slogans from another widget blog.