Skip to main content
DZap’s error model has two layers: execution errors returned when a transaction is submitted/simulated, and contract-revert errors surfaced when the on-chain call itself reverts.
Two failure shapes do not follow the patterns below:
  • 429 responses use their own body (error, retryAfter, resetTime, limit, window) — see Rate Limits.
  • Per-pair quote errors are not thrown. /v1/quotes returns 200 with the failure carried inside the pair object as status: "error" and a message, alongside pairs that succeeded. Check each pair, not just the HTTP status.

Execution status codes

StatusCodes, used in code fields across the SDK (e.g. DZapTransactionResponse.code):

Transaction status

Every SDK execution result (trade(), zap(), tradeGasless()) reports one of these in its status field: mining · success · rejected · error · reverted · pendingWalletConfirmation · partialSuccess · waitingForExecution

Contract-revert errors and recovery actions

When execution fails, the response may include an action hint telling you how to recover:

Unavailable routes

When individual providers fail but the pair still quotes, they appear under quotes[pairKey].unavailableRoutes, keyed by provider, as a ProtocolErrorInfo. The type field selects which details shape you get: AMOUNT errors carry minAmount/maxAmount in the token’s base units — surface the actual bound to the user rather than guessing a threshold.

Status endpoint terminal states

/v1/status (Trade) and /v1/status (Fuse) both report a terminal status field once the transaction settles:
  • Trade (TradeStatusResponse.status, and per-leg TxStatusForPair.status): COMPLETED · FAILED · PENDING · PARTIAL · REFUNDED
  • Fuse (ZapStatusResponse.status, and per-step ZapStatusStep.status): PENDING · COMPLETED · FAILED · REFUNDED
See Track Trade Status and Track Zap Status for polling examples.
Last modified on July 28, 2026