Skip to main content

Documentation Index

Fetch the complete documentation index at: https://dev.jup.ag/docs/llms.txt

Use this file to discover all available pages before exploring further.

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

FeatureV1V2
Trigger typePool rate only (e.g. “1 Fartcoin = 0.00025 SOL”)USD price
Order directionBuy below, sell aboveBuy above, buy below, sell above, sell below
TP/SLNot supportedTake-profit and stop-loss with OCO bundling
Edit ordersMust cancel and recreateEdit trigger price and slippage in-place
Partial fillsNot supportedOrders fill partially for optimal execution prices
Output amountGuaranteed (fixed pool rate)Not guaranteed (prioritises trigger execution, pool price may vary)
AuthenticationAPI key onlyChallenge-response JWT + API key
Order privacyPending orders visible on-chain (PDA accounts)Orders stored off-chain, private until execution
DepositsProgram-derived address (PDA) order accountsVault accounts (custodial) by Privy
Route prefix/trigger/v1/trigger/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

TypeDescriptionUse case
SingleTriggers when USD price crosses above or below a thresholdStandard limit orders, stop-loss
OCOTwo orders sharing one deposit: one take-profit, one stop-loss. When one fills, the other cancels automaticallyRisk management with TP/SL brackets (e.g. sell SOL at $300 TP or $200 SL while market is $250)
OTOCOA parent order triggers first, then activates a TP/SL pair (OCO) on the outputConditional entry with automatic exit strategy

​
How It Works

Your Wallet ──→ Vault (1 per wallet) ──→ Order A
                                    ──→ Order B
                                    ──→ Order C
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

https://api.jup.ag/trigger/v2
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.