Skip to main content
The DEX Aggregator API supports two integration shapes. They produce equivalent on-chain transactions; the difference is when the routing engine runs.

Two-step

/quote → human reviews price → /submit → broadcast.Best for swap UIs.

One-step

/execute → broadcast.Best for one-click flows and bots.
Use this flow when a user reviews the quoted price before they commit.

Pros

  • User confirms the price they see; no last-second surprise.
  • You can run validation between quote and submit (e.g. “is this trade > $X? require a confirm dialog”).
  • Clean separation between read (quote) and write (submit) for caching, analytics, and rate limiting.

Cons

  • Quotes have a TTL (~10 seconds). If the user takes too long, /submit returns 404 and you must re-quote. See Quote freshness.
  • Two API calls per swap.

One-step (instant swap)

Use this flow when there’s no preview step.

Pros

  • Single round trip.
  • No quoteId to track, no expiry to handle.

Cons

  • The user (or bot) doesn’t see the price before signing. If you still want to show it, log exec.routePlan.expectedAmountOut after the fact.
  • Less flexibility for caching and analytics, since each call rebuilds the full route plan server-side.

Choosing the right pattern

Even when you use /execute for the user-facing call, you can still hit /quote separately for live price display in the modal. Just be aware they consume separate rate-limit budget.

Always: handle expired quotes

Whichever pattern you pick, treat 404 quote not found or expired from /submit as recoverable: re-fetch /quote with the same parameters and retry. Don’t surface this as a user-facing error unless it happens repeatedly. See Quote freshness for the full pattern.