Skip to main content
The Jupiter Trigger Order API enables advanced order types on Solana, allowing users to set price conditions for token swaps that execute automatically when market conditions are met. V1 required traders to think in pool ratios — calculating how many tokens per SOL a pool needed to reach before an order would trigger. V2 replaces this with USD price triggers: set a dollar price and Jupiter handles conversion, routing, and execution. Orders are stored off-chain and private by default, closing the most common MEV attack vector of visible pending orders.

​
What’s New in V2

There are no current plans to deprecate V1. However, all development efforts, research, and maintenance are focused entirely on V2. V1 will only receive updates for critical issues.

​
Order Types

​
How It Works

Each wallet gets a single vault (a Privy-managed custodial account). When you create orders, tokens are deposited from your wallet into your vault. The vault holds funds for all your active orders.
  1. Authenticate: Sign a challenge with your wallet to receive a JWT token
  2. Get your vault: Retrieve your vault, or register one on first use
  3. Create an order: Deposit tokens into your vault and submit order parameters
  4. Monitor: Track order state and history via the history endpoint
  5. Manage: Update order parameters, or cancel with a two-step withdrawal flow

​
Base URL

All endpoints require an API key via the x-api-key header. Authenticated endpoints additionally require a JWT token via the Authorization: Bearer <token> header.

Get an API key

​
FAQ

Funds remain in the vault. To retrieve them, use the same two-step cancel flow: initiate cancellation on the expired order, sign the withdrawal transaction, and confirm. See Expired Order Withdrawal.
Yes. You can update trigger prices and slippage in-place without cancelling and recreating the order. See Update an Order.
V2 uses USD price triggers rather than pool rate triggers. When the price condition is met, the order executes a swap at the current market rate via Jupiter routing. The actual output depends on liquidity and slippage at execution time.
10 USD equivalent.
Open orders continue to be monitored and will execute normally. The JWT is only required for API calls (creating, editing, cancelling orders). When your token expires, re-authenticate to manage your orders.
A One-Cancels-Other order creates a take-profit and stop-loss pair that share one deposit. When one side fills, the other cancels automatically, returning unused funds to the vault.
A One-Triggers-One-Cancels-Other order has a parent trigger that executes first. Once the parent fills, it automatically activates a TP/SL pair (OCO) on the output tokens. If the parent expires or fails, the child orders are never created.
Take-profit and buy-below orders use auto slippage via RTSE (Real-Time Slippage Estimator). Stop-loss and buy-above orders default to 20% (2000 bps) because execution certainty is more important when cutting losses. You can always set a custom slippage.
The API accepts USD price triggers only (triggerPriceUsd). Market cap targeting is a convenience feature on the jup.ag frontend — it converts the market cap to a USD price before submitting to the API. To replicate this, divide the target market cap by the token’s total supply to get the per-token USD price.
No. V2 orders are stored off-chain and private by default. Order details (price, size, direction) are not revealed until the trigger condition is met and execution begins. In V1, pending orders were stored in on-chain PDA accounts, giving bots a roadmap to front-run profitable trades.
Not currently, and there is no timeline for adding them. There is no atomic workaround because the keeper executes the transaction and the order is opaque to integrators. The only option is to run a separate transfer transaction outside the order flow.