How to Choose a Crypto Swap API for Your Product
Choosing a crypto swap API comes down to four criteria: chain coverage for your users’ actual assets, the fee model (a markup you configure vs a revenue share from the provider’s own fee), custody architecture (non-custodial should be the default requirement), and integration effort (widget, SDK, or raw API). For wallets and trading bots specifically, the fee model matters most long-term, because it determines whether you’re inflating the cost your users see or earning from volume without changing what they pay. There’s no universally best API; the right choice depends on which chains your users are actually on and whether your revenue model needs a user-facing markup or a share of protocol fees.
What a Swap API Actually Does
A swap API handles four things so your product doesn’t have to build them from scratch: it queries liquidity across multiple DEXs, CEXs and private liquidity sources to find the best price, returns a quote with expected output and fees, constructs the transaction for signing, and, for cross-chain swaps, coordinates the bridge leg between source and destination chains. Your product calls the API, gets a route back, and the user signs a transaction (or several) built for that route.
What differs between providers is coverage, reliability, and the part that matters for your product’s economics: how you get paid for the volume you generate.
Fee Models Compared
Three fee models exist across the major providers, and they behave differently for your product’s revenue and your users’ experience.
Fixed markup / integrator fee. You configure a percentage added on top of the underlying route cost. The user pays the base cost plus your fee; you collect the difference. LiFi and Socket both work this way: LiFi’s default protocol fee sits around 0.25%, configurable per integration, and fees on supported chains route to the integrator’s wallet at execution time rather than requiring a separate withdrawal step. This is straightforward to configure and settles per-transaction, but the cost is visible to the end user as part of what they pay.
Revenue share from protocol fee. The provider charges its own fee on swap volume and splits a portion with the integrator, without adding anything on top of what the user already pays. The user’s cost doesn’t change based on which product they’re using; your revenue comes from the provider’s own take, not an added charge.
Surplus / positive slippage sharing. The integrator earns a share of execution improvement, the difference between the quoted price and a better actual execution price. This is less common as a primary integrator model and typically appears alongside one of the two models above rather than replacing it.
| Model | User Cost Impact | Settlement | Example Providers |
| Fixed markup / integrator fee | Increases user’s total cost | Per-transaction, to integrator wallet | LiFi, Socket, YiFi, Changenow |
| Surplus / slippage sharing | No change to user’s cost (only applies on favorable execution) | Varies | 1inch Fusion, CowSwap solvers |
Neither model is universally superior. A markup is simple to reason about and settles automatically per transaction without a withdrawal step. A revenue share keeps your product’s pricing identical to the underlying provider’s, which matters if you’re competing on price or don’t want your fee visible as a separate line item to users.
Chains and Coverage
Chain support varies significantly and should be checked against your actual user base, not against a provider’s total chain count. LiFi supports 60+ chains spanning EVM networks, Solana, and Bitcoin. Socket covers 20+ chains, EVM-only as of early 2026, with Solana support in beta but not yet at production parity. For teams building on Cosmos or less common chains, neither LiFi nor Socket is typically the right fit, specialized routers cover that territory instead.
YiFi’s coverage spans EVM chains (Ethereum, BNB Chain, Base, Polygon, and others), Solana, Bitcoin, Tron, Monero, and 50+ additional networks (relevant if your users hold assets outside the EVM-and-Solana set that most aggregator APIs concentrate on).
Check specific token support within a chain, not just network-level coverage. A provider can list a chain as supported while having thin or no liquidity for a specific long-tail token pair your users actually need.
Integration Effort: Widget, SDK, or Raw API
Widget. The fastest path: an embeddable UI component that handles the swap flow end-to-end with minimal code. Good for teams that want to ship quickly and don’t need custom UI control over the swap experience.
SDK. A library that handles quote-fetching, transaction construction, and route logic, while you build your own UI on top. This is the middle ground most product teams land on, enough control to match your app’s design, without building the routing logic yourself.
Rest API. Direct REST calls with no client library. Maximum control, but you handle quote parsing, transaction construction, and error states yourself. Appropriate for teams with specific performance requirements or non-standard integration contexts, such as a backend service or a bot that isn’t rendering a traditional UI at all.
For most wallet and app integrations, starting with an SDK and falling back to raw API calls for anything the SDK doesn’t expose is the practical default.
For Trading Bot Founders: Monetizing Swap Volume
If you’re running a trading bot (Telegram-based or otherwise) that executes swaps on behalf of users, the swap API you choose determines whether that volume generates revenue for you or just for the liquidity providers you’re routing through.
The mechanics are the same as for a wallet integration: your bot calls the swap API instead of the user manually swapping elsewhere, and you configure either a markup on top of the route or a revenue share from the provider’s fee. For a bot specifically, a few considerations matter more than they would for a standard wallet:
Volume concentration matters for negotiating terms. Bots that route consistent, meaningful volume through a single provider are often in a position to negotiate a better commission rate than the default published tier, worth asking about directly rather than assuming the standard rate is fixed.
Attribution needs to survive your bot’s own user flow. If your bot operates through referral codes, API keys, or wallet addresses rather than a traditional web session, confirm the provider’s attribution method actually works with how your bot identifies its own users: cookie-based attribution, common in web-first integrations, doesn’t apply to a bot architecture at all.
Transaction-level reporting matters more at bot scale. A bot executing hundreds or thousands of swaps a day needs to reconcile its own internal logs against whatever the provider reports. A monthly aggregate is much harder to audit against your own transaction count than a system that logs commission per individual swap.
For a deeper breakdown of how affiliate and revenue-share commission structures compare across providers more broadly, see Best Crypto Affiliate Programs in 2026.
How Revenue Share Works for a Developer
For an integrator-fee revenue share model like YiFi’s, the integration pattern from a developer’s perspective looks roughly like this:
1. Register at https://yifi.io/partner/ as Company (max 5 API Keys, team members on board) or Individual account (max 1 API Key, no team, refCode for promo campaigns).
2. Call the Swap API with your partner ID attached to each request: POST /v1/swap
3. The API returns a quote and a route.
Commission is calculated on the swap volume automatically, no separate fee parameter needed on your end.
4. User signs and the swap executes.
5. Check the Partners Portal (or equivalent dashboard) for transaction-level commission logging:
GET /v1/transactions/{transaction_id}
Returns: swap ID, volume, commission earned, currency, USD value at time of earning
6. Request withdrawal once you clear the minimum threshold.
The key difference from a markup-based integrator fee: there’s no fee parameter you set per request. The commission comes from the provider’s own take on the swap, calculated automatically based on your partner agreement, and settles into your dashboard balance rather than your wallet at transaction time.
For the current API reference and authentication details, see the YiFi Swap API and YiFi Earn API. For a comparison of how this custodial-with-transaction-level-logging model differs from true on-chain settlement, see how crypto affiliate payouts actually work.
Limitations
Bridge risk is inherited regardless of fee model. Whichever API you choose, cross-chain routes depend on the security of the underlying bridge selected for that transfer. Check whitelisted bridges and incident history for any provider, not just the fee structure.
Gas costs on L1 Ethereum affect small transactions disproportionately. For high-frequency bots executing many small swaps, mainnet gas can meaningfully erode margins regardless of which fee model you use. L2 and non-Ethereum chain support mitigates this.
Attribution setup requires actual integration work. Revenue share and integrator fee models both require correctly configuring partner IDs, wallet addresses, or referral parameters in your API calls. Misconfigured attribution means volume that doesn’t get credited to your account at all.
Commission rates and chain support change. Both fee percentages and supported chain lists are subject to change across all providers. Confirm current terms directly with the provider before finalizing a build.
FAQ
How do I choose a crypto swap API for my project?
Start with chain coverage: confirm the API actually supports the specific chains and tokens your users hold, not just a high total chain count. Then evaluate the fee model against your product’s pricing strategy, a markup if you want a visible service fee, a revenue share if you want your product’s pricing to match the underlying provider exactly. Confirm non-custodial execution as a baseline, check the provider’s bridge whitelist and audit history, and choose an integration path (widget, SDK, or raw API) that matches your team’s timeline and need for UI control.
What’s the difference between integrator fee and on-chain revenue split?
An integrator fee is a markup you configure on top of the swap’s underlying cost: the user pays more, and you collect the difference, typically settled directly to your wallet at transaction time on supported chains (this is how LiFi and Socket operate). A revenue share from the protocol’s own fee doesn’t change what the user pays at all, your earnings come from a portion of the fee the provider already charges, tracked and settled through the provider’s own reporting system rather than added on top.
How do I handle cross-chain swap fees in my dapp?
Decide upfront whether you want fees visible to users as an added markup or absorbed into your revenue share from the provider’s existing fee. For a markup, configure the integrator fee parameter your provider’s API exposes and display it transparently in your UI. For a revenue share, no additional fee configuration is needed on your end. Track your earnings through the provider’s partner dashboard instead. Either way, confirm how the provider handles fee display and rounding for cross-chain routes, since costs can be split across multiple legs (source-chain gas, bridge fee, destination-chain gas).
How can a trading bot monetize its swap volume?
Route your bot’s swaps through a swap API configured with your partner ID, using either a markup or a revenue-share model depending on your pricing approach. Since bots often use API keys or wallet addresses rather than cookie-based attribution, confirm your chosen provider’s attribution method actually works with your bot’s architecture before launch. At meaningful volume, transaction-level commission reporting makes it possible to reconcile your bot’s internal swap logs against what the provider reports, which matters more at bot scale than for lower-volume integrations.
Is the swap API non-custodial?
It depends on the provider, and this should be one of the first things you confirm, not an assumption. Reputable swap APIs, including LiFi, Socket, and YiFi, execute swaps non-custodially, meaning funds route directly from the user’s wallet to the destination without the provider holding a balance mid-transaction. Note this is separate from how integrator commissions are paid out: a swap being non-custodial for the end user doesn’t necessarily mean the integrator’s own commission settlement is on-chain rather than dashboard-based.
How long does integration take (widget vs SDK vs API)?
A widget integration is typically the fastest, often deployable within days since it handles the full swap flow with minimal custom code. An SDK integration takes longer, typically one to a few weeks, since you’re building your own UI on top of the library’s quote and transaction logic. A raw API integration takes the longest and requires the most engineering effort, since your team handles quote parsing, transaction construction, and error handling directly; appropriate when you need control the SDK doesn’t expose, such as in a backend bot service without a traditional UI layer.
Get Started
For technical integration details, authentication, and endpoint reference, see our API documentation.
For a broader comparison of DEX aggregators by chain coverage and routing model, see Best DEX Aggregators in 2026. For a full breakdown of how crypto affiliate and revenue-share programs compare across the industry, see Best Crypto Affiliate Programs in 2026.