Skip to main content
The JupiterZ API lets you source RFQ liquidity directly: request a firm quote from Jupiter’s market makers, have the user sign the returned transaction, and send it back for execution. The market maker co-signs and submits the transaction on-chain, so you never build or land the transaction yourself. This page is for integrators consuming quotes: wallets, aggregators, trading UIs and bots. On the Meta-Aggregator path, JupiterZ competes with the other routers for the best price; the JupiterZ API skips the competition and quotes RFQ market makers only. If you are a market maker looking to provide liquidity, see Integrate MM into JupiterZ.

Base URL and authentication

Every request must carry an API key from the Developer Platform in the x-api-key header. Requests without it return 401 Unauthorized.
Access to the JupiterZ API is whitelisted: your API key must be enabled for it before the endpoints respond. To request access, reach out via the enterprise form.

How it works

The transaction returned by /order is a base64-encoded versioned transaction. The taker signs it (a partial signature), then the market maker adds the final signature and submits it on-chain. Market makers quote a firm price: orderInfo amounts have equal startAmount and endAmount, so there is no slippage range and no slippage parameter.

Quick start

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

Prerequisites

Code example

Sign the transaction as-is. Rebuilding it, reordering instructions or changing amounts invalidates it: the market maker verifies the transaction it originally quoted before co-signing.

Getting an order

GET https://api.jup.ag/swap/v2/jupiterz/order asks every eligible market maker for a price and returns the best one. See the API reference for all parameters, including integrator fees (integratorFee, integratorTokenAccount, integratorFeeSide) and Squads vault swaps (settingsPda, signers). The integratorTokenAccount must already exist: pre-initialise the associated token account for the fee mint, because the API does not create it. All amounts are strings in the token’s smallest unit, so no precision is lost: "1000000" is 1 USDC (6 decimals), "1000000000" is 1 SOL (9 decimals).

Quote expiry

expireAt is a Unix timestamp (seconds) after which the transaction is no longer valid. Sign and execute before it passes. Executing an expired quote returns 400 with errorCode: "QUOTE_EXPIRED"; request a fresh order instead.

Indicative quotes

Two cases return a price but no transaction, so you can display pricing before the user is ready to trade:
  • No taker: there is nothing to build a transaction against. error is omitted.
  • taker provided, but the transaction cannot be built: error explains why.
Always check that transaction is non-null before signing.

No quote available

When no market maker quotes the pair, /order returns 404 with errorCode: "NO_QUOTE_FOUND". Fall back to another liquidity source, such as the Meta-Aggregator.

Global order

GET https://api.jup.ag/swap/v2/jupiterz/global-order quotes one input mint against several candidate output mints and returns only the leg worth the most in USD. Useful when you do not care which stablecoin (or wrapper) the user ends up with, just which one pays best. Parameters are identical to /order, with two differences:
  • outputMint takes a comma-separated list of mints (currently up to 3).
  • ExactIn only.
The response has the same shape as /order. orderInfo.output.token tells you which mint won, and requestId identifies that winning leg. Pass the requestId and quoteId to /execute unchanged. The candidate list is capped server-side (currently 3 mints, duplicates ignored). Passing zero mints or more than the cap returns 400.

Executing

POST https://api.jup.ag/swap/v2/jupiterz/execute takes the taker-signed transaction and hands it to the market maker, who adds the final signature and submits it to Solana. The body is requestId, quoteId and the signed transaction, all from the order response.

States

A rejected or failed swap still returns 200 OK with the state in the body. Check state, not just the HTTP status.

Pending confirmations

An accepted response means the transaction was submitted but not yet seen as confirmed. Calling /execute again with the same requestId is safe: it does not re-execute the swap, it re-checks the existing one and returns confirmed with the signature once it lands. The quick start code above shows the re-check loop.

Errors

Errors use a consistent JSON body:
error is always present. errorCode is null unless the failure maps to one of the codes below.