Skip to main content
The Trigger Order V2 API is in beta and under active development. Behaviour, endpoints, and response formats may change as we iterate based on integrator feedback. Pin to specific response schemas and handle unknown fields gracefully.

Reference Implementation

The jup.ag frontend is the canonical reference for how to interact with the V2 API. When in doubt about edge cases, validation logic, or UX patterns, refer to how jup.ag handles it. This includes:
  • Order creation flows and parameter validation
  • Price and slippage presentation
  • Error handling and retry logic
  • Order state management and polling

Order Expiry

Every order requires an expiresAt timestamp. Unlike V1 where orders could exist indefinitely, V2 enforces expiry on all orders. This allows the system to prune stale orders, improving execution quality for active orders.
Use caseRecommended expiry
Short-term trades1-7 days
Swing trades7-30 days
Long-duration positions30 days, with periodic renewal
For long-lived orders, set a 30-day expiry and renew by updating the order before it expires via the update endpoint. There is no “no expiry” option by design.

Slippage

Order typeDefaultRecommendation
Take-profit / buy belowAuto (RTSE)Use the default unless you have specific requirements
Stop-loss / buy above20% (2000 bps)Keep high for execution certainty — tighten only if you accept missed fills
Parent (OTOCO)Auto (RTSE)Use the default
Stop-loss orders use a higher default because execution certainty matters more than price precision when cutting losses. If you lower stop-loss slippage, the order may not fill during volatile conditions.

Error Handling

  • Validation errors (400) include a details object with per-field messages. Parse these to surface specific issues to users.
  • Authentication errors (401) mean the JWT has expired. Re-authenticate with a new challenge-response flow rather than retrying the same token.
  • Minimum order size is 10 USD. Enforce this client-side to avoid unnecessary API calls.
  • Handle unknown fields in responses gracefully. As the API evolves during beta, new fields may be added to response objects.

Order Summary

The API does not validate whether your trigger price makes economic sense. If a user sets a buy order above market price or a sell order below market price, the keeper will execute as instructed and the difference is lost. Display a human-readable summary of what the order will do before the user confirms. On jup.ag, the confirmation shows a plain-language description like:
Buy SOL with 15 USDC when price goes below 76.37(1076.37 (-10% from market). If triggered, automatically set TP for SOL at 84.01.
This helps users catch mistakes before submitting. For OCO and OTOCO orders, include both the trigger conditions and the child order parameters in the summary.

Token Compatibility

  • Tokens with transfer tax extensions (Token-2022) are not supported
  • Input and output mints must be different

Order Lifecycle

Poll the history endpoint to track order state. Key states to handle:
StateMeaningAction
openActive, waiting for triggerNo action needed
filledFully executedShow completion to user
cancelledCancelled by userConfirm funds returned to vault
expiredPast expiresAtPrompt user to withdraw funds or recreate
failedExecution failedShow error, suggest retry with adjusted parameters