Integrate swaps into your dapp on Robinhood Chain

If you are building on Robinhood Chain and your app needs swaps, the work you probably do not want to take on is routing: discovering pools, comparing fee tiers, simulating splits, encoding router calldata, and keeping all of it correct as liquidity moves. Splitshot exposes the routing engine behind its own app as a public REST API, and the integration surface is deliberately small: one GET request returns both the quote and a transaction you can send as-is.

One call, quote plus calldata

Here is the entire integration in its minimal form:

curl "https://splitshot-dex-be.onrender.com/v1/quote?tokenIn=0x0Bd7D308f8E1639FAb988df18A8011f41EAcAD73&tokenOut=0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168&amountIn=1000000000000000&recipient=YOUR_ADDRESS&slippageBps=auto"

The response carries amountIn, amountOut, the split legs the router chose, autoSlippageBps when you asked for automatic tolerance, and a tx object with to and data. Pass tx.to and tx.data to your user's wallet and the swap executes as a single SwapRouter02 multicall with one combined minimum-output floor across every leg. There is no SDK to install and no ABI to maintain; if your stack can make an HTTP request and send a transaction, it can swap.

This is not a simplified demo path. It is the same flow the Splitshot app itself runs on mainnet, which means the quirks have been found by real trades rather than left for your users to discover.

The parameters

The endpoint takes a handful of query parameters, and they map cleanly onto the decisions a swap actually involves:

• tokenIn and tokenOut: the 0x addresses of the pair. For native ETH, use the WETH address; the flags below handle wrapping.
• amountIn: the amount as a uint string in wei. With exactOut=1, this becomes the desired output amount instead.
• recipient: who receives the output. Required whenever you want calldata back, since the transaction encodes it.
• slippageBps: a fixed tolerance from 0 to 500 basis points, or auto to let the engine derive tolerance from the trade's own measured price impact.
• exactOut=1: quote by desired output. The response adds amountInMaximum, the most the trade can spend; anything unspent refunds inside the same transaction.
• nativeOut=1: appends an unwrap step so the recipient receives native ETH rather than WETH.
• nativeIn=1: signals native ETH in; you send amountIn as the transaction value and the router wraps it.

Native ETH, both directions

Most users hold native ETH, not WETH, and integrations that force a manual wrap step lose people at exactly that point. The API absorbs it. For ETH in, request the quote with the WETH address as tokenIn and nativeIn=1, then send the returned transaction with the input amount as its value. No approval is needed, because there is no token allowance involved, which makes this a natural first-swap path for a brand-new wallet. For ETH out, add nativeOut=1 and the router unwraps at the end, so the recipient sees plain ETH in their balance rather than a token they have to go unwrap themselves.

ERC-20 inputs need the standard one-time approval of SwapRouter02 before the first swap; after that, every quote is directly sendable.

Exact output when the amount matters

Sometimes the product requirement is not "swap this much" but "end up with exactly this much": a checkout priced in a stablecoin, topping an account up to a target, funding a position of a precise size. That is what exactOut=1 is for. You specify the output you want, the response tells you the maximum input it may take (amountInMaximum), and the transaction refunds whatever the fill does not consume. Your interface can show users a hard number for what they will receive and a worst case for what they will pay, which is a much easier thing to design around than an estimate with error bars.

Slippage you do not have to explain

Hardcoding a tolerance for someone else's trades is guesswork: too tight and their swaps revert on normal jitter, too loose and you have quietly authorized bad fills. Passing slippageBps=auto delegates the decision to measurement. The engine probes a fraction of the trade to estimate its real price impact and sets the tolerance from that, clamped between 10 and 500 basis points, then reports the chosen value back as autoSlippageBps alongside priceImpactBps. Small trades in deep pools get tight floors automatically; large trades in thin pools get honest room. Your UI can simply display what was chosen and why.

Where the canon lives

Everything above is the orientation tour. The reference material stays with the docs, and those are the pages to build against rather than any blog post, this one included:

• The quickstart takes you from zero to a sent swap transaction in about five minutes, including the wallet-side code.
• The Swap API reference documents every parameter and response field, with worked patterns for native ETH in, native ETH out, and exact output.

Chain-side, this all runs on Robinhood Chain, chain ID 4663, where blocks arrive in roughly 100 milliseconds and a measured swap cost under two US cents in gas as of July 15, 2026. Quote, send, confirmed: on this chain the whole loop fits inside a user's attention span, which is exactly what an embedded swap should feel like.