Preferred and restricted liquidity

If you integrate the FX API and run Stitch, you can steer RFQ toward your own operator wallets. Two fields, and you pick one:

Field	Behavior
preferredLiquidityWallets	Solicit these wallets first, then fall back to the open market
restrictedLiquidityWallets	Solicit only these wallets, with no open-market fallback

Up to 10 Stitch operator addresses. Omit both and nothing changes. Sending both is a 400.

Steering needs no credential. The lists are honoured for any caller, so a shared deep link prices the route it names.

Swap (RFQ)

POST /v2/rfq/preview and POST /v2/rfq/request accept the same two fields. Preferred asks your wallets first, with a short head start, then the rest of the makers. Restricted never leaves your list. If none of them quote, you get no_restricted_liquidity.

The firm quote's routing object reports preferenceApplied, restrictionApplied, fallbackUsed, and how many quotes came back from preferred against open-market makers.

POST /v2/rfq/request
{
  "chainId": 56,
  "sellToken": "0xCNGN",
  "buyToken": "0xUSDT",
  "sellAmount": "1000000000",
  "taker": "0xYourWallet",
  "preferredLiquidityWallets": ["0xYourStitchWallet"],
  "takerProof": { "nonce": "0x…", "issuedAt": 1756400000000, "signature": "0x…" }
}

The firm request still needs takerProof, one signature by the taker wallet proving you hold it. Drop it if you call with a partner API key, and leave it out of preview, which never needs it. See Proof of control and RFQ endpoints.

Limit orders

v1 is closed to new integrations

Limit steering runs on the deprecated v1 API. It stays served for integrations already on it, but do not build anything new there. Everything above is v2.

FastFill prices against a listed maker when one can fund the whole order. Preferred falls back to the market when they cannot. Restricted returns fastFillUnavailableReason: "no_restricted_liquidity" instead.

When listed wallets are used on prepare, the signed order gives those wallets an exclusive fill window of 15 seconds, then opens to every filler automatically, with no second signature. Restricted only controls whether pricing may leave your wallet list.

Quote:

GET /v1/limit-orders/quote?...&preferredLiquidityWallets=0xBotA,0xBotB

Or restrict:

GET /v1/limit-orders/quote?...&restrictedLiquidityWallets=0xBotA,0xBotB

The response tells you whether listed liquidity was used: usedPreferredLiquidity, usedRestrictedLiquidity, fallbackUsed, targetFillerWallet.

Prepare with the same wallets when you want the 15-second exclusivity window. Set deadline to now + 600 in unix seconds. Submit rejects TTLs longer than about a year, so do not paste a far-future constant.

POST /v1/limit-orders/prepare
{
  "chainId": 8453,
  "maker": "0xYourWallet",
  "sellToken": "0xCNGN",
  "sellAmount": "1550000000",
  "buyToken": "0xUSDT",
  "pricing": { "mode": "fastFill" },
  "deadline": 1785667200,
  "restrictedLiquidityWallets": ["0xYourStitchWallet"]
}

The 1785667200 above is just now + 600 as of writing. Compute it at request time.

If preferred wallets cannot fund a FastFill-priced order, prepare falls back to market pricing and does not attach exclusivity, so you never lock the order to wallets that could not take it. With restricted wallets, prepare rejects instead of falling back. Zero addresses are rejected at the request boundary.

Full flow: Limit orders.

Rules of thumb

• Use the same wallet field on quote and trade. Do not mix preferred on quote with restricted on execute.
• Maximum 10 addresses. Duplicates are deduped, and checksum or lowercase both work.
• Listed wallets must be Stitch operator liquidity. Trader limit orders do not count.
• Restricted means no open-market fallback. On Limit, the on-chain 15-second exclusivity window still opens afterward, so the order does not stall if your bot is offline.