Handle liquidityAvailable false in 0x responses

A 0x response with liquidityAvailable: false is a valid outcome your adapter must understand. It should not fall through to code that assumes a transaction object exists.

The 0x FAQ explains that other response parameters can be omitted when liquidity is unavailable. Model this as a separate response variant rather than making every transaction field optional throughout the application.

Parse the outcome first

At the API boundary, validate the transport result, then the provider response. If liquidity is unavailable, return an application result containing the request identity and an unavailable reason. Construct an executable quote only from the branch whose required fields pass validation.

This design prevents code such as a default empty recipient or empty calldata from reaching the wallet. Missing execution fields should never become zero values merely to satisfy a type declaration.

Retire the previous result

Suppose a hypothetical user changes the input from a small amount to a much larger amount. The small request succeeds; the large request has no route. Keeping the old quote card active would pair the new form with a transaction for the previous amount.

Invalidate execution as soon as the input changes, and apply responses only to their matching request generation. A delayed successful response for the small trade must not reverse the newer unavailable state.

Describe the scope accurately

Say that no route was returned for this request. That is narrower than claiming the token has no liquidity anywhere. Chain, amount, source filters and provider capabilities can all affect the request outcome.

Allow the user to adjust the form deliberately. Do not silently reduce the trade amount or broaden source filters and submit the resulting trade. Any changed economic terms belong in a fresh review.