POST /trigger/v2/orders/dca. This page covers creating an order; see Track a DCA Order to monitor it and Cancel a DCA Order to withdraw the unfilled remainder.
How it works
Every wallet has one Privy-managed vault. You fund a DCA order by depositing into that vault, then the keeper draws from it each round: You manage two moments: creating the order (deposit + schedule) and optionally cancelling it (withdraw the unfilled remainder). Everything in between, the per-round swaps, is handled by the keeper.Order types
SetorderType on create to choose how rounds execute.
Both types retry a stuck round within a window of
min(max(30, intervalSeconds / 2), 7200) seconds before rescheduling it.
The deposit’s
orderType is dca (with no orderSubType). That is a different field from the create call’s orderType (time_based or price_conditional) above, which selects the DCA behaviour.Quick start
Creating a DCA order is four calls: authenticate, get your vault, craft and sign the deposit, then submit the order.Prerequisites
Prerequisites
Install the signing dependencies:You also need a Jupiter API key and a funded wallet. The example below loads the wallet from
BS58_PRIVATE_KEY and the key from JUPITER_API_KEY in your .env. For the browser-wallet (signMessage) version of authentication, see Authentication.200 means the order is live. The response is { id, txSignature }, where txSignature is the on-chain deposit signature:
The vault address is resolved from your JWT, so you never pass it. The deposit
requestId is single-use and is consumed by the create call as depositRequestId. Once the order is live, track it.Request parameters
The body ofPOST /trigger/v2/orders/dca:
Validation
The API validates the request before any funds move, so a rejected order costs nothing.
Active orders are those in
depositing, active, executing, or withdrawing. Cancel orders you no longer need to free up slots.
Price-conditional orders
To accumulate only within a target price range, setorderType: "price_conditional", at least one of minPriceUsd / maxPriceUsd, and a triggerMint:
triggerMint must be the input or output mint, and cannot be the stablecoin side of the pair. In practice that is the volatile leg (here, SOL). A stablecoin trigger such as USDC is rejected with 400 "Trigger mint is not supported", and a pair where both legs are stable returns 400 "Mint pair is not supported". Omitting the bounds or the trigger returns a 400 identifying the missing field, and a time_based order that sets price bounds is rejected.
Errors
Beyond the create-time validation above, these are the runtime errors you are most likely to hit across the DCA endpoints:Related
Track a DCA Order
Monitor progress, fills, and state.
Cancel a DCA Order
Withdraw the unfilled remainder.
Create DCA Order (API)
Full request and response schema in the API reference.
Authentication
The challenge-response JWT flow every request needs.
