The Swap API V2 routes through multiple liquidity sources. Which endpoint you use and which parameters you pass determines which routers are eligible, directly affecting the price you get.
Routing architecture
Jupiter’s routing combines multiple engines and selects the best execution price across all of them, with a self-learning mechanism that automatically sidelines underperforming sources.
| Engine | Role |
|---|
| Metis | Jupiter’s onchain routing engine. Multi-hop, multi-split swaps across Solana DEXes. Also available as an independent public good. |
| JupiterZ | RFQ (Request for Quote) system where market makers compete to provide off-chain liquidity. Often beats onchain by 5-20bps on major pairs. |
| Dflow | Third-party decentralised order flow. |
| OKX | Third-party OKX liquidity. |
Router Availability
Not all routers are available on every endpoint. This is the most common source of confusion for integrators:
| Endpoint | Routers | Notes |
|---|
/swap/v2/order (no optional params) | Metis, JupiterZ, Dflow, OKX, etc | All routers compete. Best price. |
/swap/v2/order (with optional params) | Depends on params | See routing impact matrix below. |
/swap/v2/build | Metis only | Returns raw instructions. No JupiterZ (RFQ), no third-party routers. |
Swap V1 (/v6/quote + /v6/swap) | Metis only | Legacy endpoint. Same Metis engine, no aggregation. |
If you are using /build, you are only getting Metis routing. You cannot access JupiterZ (RFQ) because MMs in JupiterZ only accepts orders coming from our backend.For use cases that involve modifying of transactions, such as CPI, adding/changing instructions or any part of a transaction are not allowed for JupiterZ, since validation is not trivial and not all MM will/can support today.
Routing Impact Matrix
Adding optional parameters to /order can restrict which routers are eligible. This table shows the impact:
| Parameter | Metis | JupiterZ (RFQ) | Dflow | OKX |
|---|
| (no optional params) | Yes | Yes | Yes | Yes |
receiver | Yes | No | Yes | Yes |
referralAccount & referralFee | Yes | No | Yes | Yes |
payer (integrator gasless) | Yes | No | No | No |
excludeRouters: jupiterz | Yes | No | Yes | Yes |
receiver, referralAccount, referralFee or payer disables JupiterZ (RFQ), which may result in worse pricing on major pairs where market makers often beat onchain routing by 5-20bps.
For the full parameter reference, see the API reference.
Order Mode
The /order response includes a mode field that tells you which routing behaviour was applied:
| Mode | Meaning | Routers |
|---|
| ultra | No optional params used. All routers competed. Best price. | Metis, JupiterZ, Dflow, OKX |
| manual | Optional params detected. Routing may be restricted. | Depends on which params are set |
mode to verify your request got the routing behaviour you expected. If you see "mode": "manual" but didn’t intend to restrict routing, check which optional parameters you are passing.
This is similar to how our jup.ag frontend behaves, when you use custom settings like slippage, priority fee strategy or dex/router exclusions, you will get a different mode.
Integrate into Routing
If you want your liquidity routed through Jupiter:
