Skip to main content
The Meta-Aggregator is the recommended way to swap on Jupiter. All routing engines compete for the best price (Metis, JupiterZ RFQ, Dflow, OKX), and Jupiter handles transaction landing for you via /order + /execute.

Quick start

Three steps: get an order, sign it, execute it.

Prerequisites

There are several ways to load a wallet for testing. All examples on this page use BS58_PRIVATE_KEY from your .env file.
Never commit private keys to source control. Use environment variables or the Solana CLI keyfile for testing. In production, use a proper key management solution.

Code example

How it works

1. Get an order

GET /order returns a quote and an assembled transaction in a single call. All routers compete for the best price: Metis, JupiterZ, Dflow, and OKX.
Adding optional parameters to /order (such as fee or slippage overrides) may restrict routing. See the routing impact matrix below for details.
Required parameters: Key response fields: When transaction is an empty string, the response still contains valid pricing (inAmount, outAmount) but the swap cannot proceed. Handle this in your integration:
For the full parameter reference, see the API reference. For how each parameter affects routing, see the routing impact matrix below.

Transaction validity

Sign and submit the transaction as soon as you receive it. The longer you wait, the more the quote goes stale as onchain prices move.
  • Aggregator routes (Metis, Dflow, OKX): lastValidBlockHeight in the response is the hard expiry. The transaction becomes invalid after this block height.
  • RFQ routes (JupiterZ): expireAt is the quote expiry timestamp from the market maker. RFQ quotes are typically shorter-lived than aggregator quotes.
These are guidelines, not guarantees of execution. Prices can move against you even within the validity window, causing the transaction to fail due to slippage. Sign and submit immediately after receiving the order.

2. Sign the transaction

  • The transaction returned by /order is unsigned. Sign it with your wallet’s private key. The example above uses @solana/kit. The transaction is a versioned transaction (v0).
  • Note: we use the partiallySignTransaction for partial signing because when JupiterZ routing is provided, there is an additional signer which is the MM that will be required after sending the transaction to /execute request.

3. Execute the transaction

POST /execute takes the signed transaction and the requestId from the order response.
/execute has its own dedicated rate limit bucket (Keyless 20, Free 50, Paid 100 RPS), separate from your general API limit. See Rate Limits.
Jupiter handles:
  • Optimised slippage via RTSE (Real-Time Slippage Estimator), applied at order time to balance trade success and price protection
  • Optimised priority fee strategy for current network conditions
  • Jupiter Beam (our own proprietary transaction execution pipeline) for accelerated transaction sending and landing across multiple RPC providers
  • Confirmation polling
  • Parses both successful and failed transactions
Request body: Response: Use totalInputAmount and totalOutputAmount for the swap token amounts reflected in the user’s wallet. Use inputAmountResult and outputAmountResult for swap-route accounting. The swap fee is collected in one token, shown by feeMint in the /order response. If feeMint matches inputMint, compare totalInputAmount and inputAmountResult:
If feeMint matches outputMint, compare outputAmountResult and totalOutputAmount:
For example, if /execute returns:
The swap route produced 2103 output units, and 2101 output units were reflected in the user’s wallet. The difference is the fee collected in the output mint.

Error codes

/order error codes

When /order returns transaction: "" (empty string), the response still contains valid pricing but the swap cannot proceed. The errorCode and errorMessage fields explain why. The same errorCode number has different meanings depending on the router. Match on both fields: Aggregator routers (metis, dflow, okx): JupiterZ router (jupiterz):

/execute error codes

The code field in the /execute response indicates the result. 0 is success, negative values are errors grouped by router type:

Routing impact matrix

Adding optional parameters to /order can restrict which routers are eligible: Key takeaway: setting payer to a wallet different from taker disables JupiterZ (RFQ) and restricts routing to Metis, 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 indicates whether optional parameters were applied that may affect routing or swap behaviour: mode does not indicate which router was used for the swap. It signals whether you adjusted parameters that could affect price or swap success. This is useful for debugging: if a swap fails in manual mode, the parameter modifications you applied may be the cause.
This is similar to how the jup.ag frontend behaves: when you use custom settings like slippage, priority fee strategy, or dex/router exclusions, the swap is handled differently. Since you opted into custom parameters, you take responsibility for the impact on swap outcomes.

Fees

Jupiter platform fee

Jupiter charges a platform fee on /order swaps. This fee is included in the quote and deducted automatically. The platformFee field in the response shows the fee amount and rate:

Total fee vs platform fee

The top-level feeBps field is the total fee rate charged for the swap. The platformFee.feeBps field is the Jupiter platform fee rate, which is the fee Jupiter intends to make from the swap. These values can differ when the swap includes additional charges, such as gasless support cost recoup. For example, if the platform fee for a swap pair is 5 bps and gasless support adds 7 bps, the response can show feeBps: 12 and platformFee.feeBps: 5.

Fee breakdown

The platform fee varies by token pair:

Fee mint priority

Jupiter determines which token to collect fees in based on a priority list:
  1. SOL
  2. Stablecoins (USDC, USDT, etc.)
  3. Liquid staked tokens (jupSOL, etc.)
  4. Bluechips (large market cap tokens)
  5. Others
Check the feeBps, platformFee.feeBps, and feeMint fields in the /order response to see the total fee rate, Jupiter platform fee rate, and fee token for your swap.

Referral fees

Use the Jupiter Referral Program to earn fees on /order swaps. This requires setting up referral accounts before you can collect fees.

How it works

  • Jupiter takes 20% of your integrator fee (no separate platform fee when referral is active)
  • Jupiter decides which token mint to collect fees in based on the fee mint priority list
  • You must create a referralTokenAccount for each mint you expect to receive fees in
  • If the referralTokenAccount for the feeMint is not initialised, the order still returns but executes without your fees (the user still gets their swap)
  • Fee range: 50 to 255 bps
  • Supports SPL and Token2022 tokens

Setup

Three one-time steps before you can collect fees:
  1. Install the Referral SDK
  1. Create a referralAccount (once)
  1. Create referralTokenAccount for each fee mint
Create a token account for each mint you expect to collect fees in. Start with SOL and USDC. You can add more later.
You can also use the Referral Dashboard to create accounts via a web interface.

Usage

Pass referralAccount and referralFee to /order:
Verify your fees are applied by checking the response fee fields. Top-level feeBps is the total fee rate charged for the swap, while platformFee.feeBps is the Jupiter platform fee rate. If the response falls back to the default platform fee, the referralTokenAccount for that feeMint is likely not initialised.

Fee response fields

The /order response includes these fee-related fields: