Building on super bridge: Which Route Type Fits?

3 route types define what your integration does with a transfer: bridge, cross-chain swap, or swap. When you build around super bridge, the right choice follows the user’s intended end state. The API returns provider quotes for these route types, with transaction steps and fee details you can use to present the trade-offs.

Choose by the asset the user needs at the end, then make cost and execution steps visible before they sign.

Which super bridge route type fits the user's action?

A bridge moves an asset from one chain to another, while a swap changes an asset on the same chain. A cross-chain swap does both in one flow, so the user can start with one token on one network and receive another token on a different network.

For a bridge interface focused on moving the same asset between networks, use the bridge route. If the user wants a different asset but will stay on the current network, use a swap; if they need a different asset on a destination network, the cross-chain swap matches that intent.

These labels describe the outcome, not the security model. Routes can rely on different providers and underlying transfer mechanisms, so a “bridge” result alone does not tell you how funds move or how long settlement takes.

What should you compare across route quotes?

Compare what the user receives, the fees, and the steps required before optimizing for speed or a low headline fee. Superbridge’s route response includes the received amount, minimum received amount, fee groups, and a sequence of transaction or wait steps.

• Output: Show the receive amount and minimum amount, especially when the route includes a swap and the result can be affected by price movement.
• Fees: Add up provider fees and the network gas the user must pay; a cheaper quote in one fee line may not mean a cheaper transaction overall.
• Steps: Check whether the user must approve a token, sign more than one transaction, or wait for a later step to become ready.
• Availability: Handle provider errors and missing routes clearly. A route can be unavailable for the requested token, amount, or chain pair.

Don’t assume the first result is the best for every user. A route with fewer steps may suit someone who values convenience, while a route with a different provider or settlement process may better fit a user who prioritizes how the asset is transferred.

How should you build around a route?

Start with the user’s source chain, destination chain, tokens, and amount, then request routes and display the available results. The route type is returned with each successful quote, alongside the transaction data needed to start execution.

Quotes can go stale as chain conditions change. Refresh them before the user submits; Superbridge recommends refreshing routes every 30 seconds, since an old quote may revert onchain.

For most integrations, expose all three types only when the product supports all three user outcomes. If your flow has one clear purpose, keep the choice narrow and explain the receive amount, fees, and required confirmations so the user can judge the route without guessing.