You can execute a ParaSwap API quote safely by binding the transaction to the intended wallet, chain, token amounts, and minimum output, provided you refresh the quote before signing. The integration has two stages: get a route, then build transaction data from that route. Understanding how ParaSwap builds swap routes helps explain why the route returned by the first call must stay paired with the trade details used in the second.
Build the transaction from the exact quote
Use the quote response as the source of truth for transaction construction. Request a route from /prices with the network, source and destination token addresses, and source amount in the token’s smallest units; for example, 1 USDC is 1,000,000 units when the token has six decimals. Then pass the returned priceRoute unchanged to /transactions/{network}, along with the same token addresses and the wallet’s address.
Do not rebuild the route from only its displayed output amount. The response includes routing and contract data needed to create valid calldata, and the transaction builder can use that route to check balances, allowances, and gas. A quote is not a reservation: pool prices can move between the API call and execution, so a transaction may revert if its minimum output is no longer available.
Set slippage according to the trade and the user’s tolerance, then let the builder encode the resulting minimum output. For a sell quote of 1,000 USDC for 0.5 ETH, a 0.5% slippage limit means the swap must return at least 0.4975 ETH. The trade-off is direct: a tighter limit protects the user’s price but is more likely to revert during volatile markets.
Check approvals and transaction fields before signing
For an ERC-20 input token, the wallet must approve the route’s tokenTransferProxy to spend the required amount; approving the router address instead may not authorize the transfer. Prefer an exact-amount approval for a one-off swap, or reuse a larger allowance only when the user knowingly accepts that ongoing permission. Native ETH input does not need an ERC-20 approval.
Before presenting a signature request, confirm the wallet is connected to the requested chain and that the built transaction targets the expected contract. Check its to, data, and value fields, and make sure the input amount and recipient match the user’s intent. Estimate gas with the wallet or current node state; a gas estimate from the quote can change before submission.
Refresh quotes when trade details change
Fetch a new route whenever the user changes the amount, token pair, network, or slippage choice. Treat a route from a previous screen state as stale even if only a short time has passed: the pool state may have changed, and the quote’s block number helps identify when it was computed. If the build call fails its checks, refresh the quote and rebuild instead of repeatedly sending the same calldata.
For a concrete before-and-after, suppose the user first quotes 1,000 USDC for 0.5 ETH, then increases the trade to 2,000 USDC. Reusing the first route with the new amount can mismatch the route and transaction parameters; the safe sequence is to request a new quote for 2,000 USDC, build from that response, and show the new minimum received amount before signing.
Keep the integration flow small and explicit
Implement the swap as a short sequence the wallet can review: request the quote, show output and minimum received, build calldata with the chosen slippage, obtain any required approval, then submit the swap transaction. ParaSwap’s API can supply the route and transaction data, but the integrator still owns the user-facing checks and signing flow.
- Read the wallet’s chain and address, then verify both match the requested swap.
- Fetch a fresh quote using token addresses and base-unit amounts.
- Show the quoted output, slippage limit, and minimum output to the user.
- Build transaction data from the unchanged route and the chosen slippage.
- Request the required approval, then simulate or estimate gas and submit the swap.
In my view, the key integration decision is to refresh on every material input change and make the minimum output visible before signing. That keeps the API route, the user’s consent, and the submitted transaction aligned.
Top comments (0)