Rebuild an existing plan with fresh pricing, without losing slippage protection

Use the refresh object from a prior SwapPlan response (or GET/derive buildId from buildId field) instead of calling POST /swap again with the same quoteId — this endpoint enforces two things POST /swap alone doesn't: the slippage ceiling never loosens across refreshes (effectiveSlippageCap), and if the underlying route's final destination address changed (not just repriced — a genuinely different router), it fails closed with 409 route_changed instead of silently swapping you into a different route. When the original provider disappears from the fan-out entirely, the 409 response embeds the current best route ready to use in error.details.alternative, so you don't need a third round trip.

post/swap/{buildId}/refresh

Request

  • Base URL: https://swap.vurto.cc/v1
  • URL: https://swap.vurto.cc/v1/swap/{buildId}/refresh
  • Auth: none required

Path parameters

buildIdstring uuid required

Request body

walletstring required

Same EVM address used to build the original plan.

slippageBpsinteger

0-10000. Clamped down to the original build's maxSlippageBps when one was set; never loosened.

Response

OK, a new SwapPlan with a new buildId

buildIdstring uuid

Identity of this specific build. Use in POST /swap/{buildId}/refresh.

buildHashstring

sha256 canonical hash of chainId + wallet + destination + calldata + value. Recompute and compare before signing if you don't trust the transport.

walletstring
chainIdinteger
validUntilinteger

Unix ms. The build expires 10 minutes after creation; call refresh after this.

slippageBpsinteger

Only present on refresh responses: how many bps the output dropped versus the original build. 0 when the price didn't get worse.

Changes

No recorded changes to this operation across all 1 revision of this API.