For the complete documentation index, see llms.txt. This page is also available as Markdown.

Integrating Squid Intents

Integrating Squid Intents follows the same flow as a standard Squid integration. If you already have Squid integrated, the only steps are to have Squid Intents enabled on your integrator ID, poll for status with a quoteId, and handle the transaction request type.

Squid Intents must be enabled on your integrator ID. Reach out to the Squid team to get started.

Route Request

Squid Intents uses the /v2/route endpoint. When Squid Intents is enabled and a route is available, it will be automatically selected.

There are no expiry constraints — You do not need to submit the transaction within a time window.

EVM Route Request Example

const params = {
  fromAddress: signer.address,
  fromChain: "42161",          // Arbitrum
  fromToken: usdcAddress,
  fromAmount: amount,
  toChain: "1",                // Ethereum
  toToken: nativeToken,
  toAddress: signer.address,
  quoteOnly: false,
};

// Get the route
const routeResult = await axios.post(
  "https://v2.api.squidrouter.com/v2/route",
  params,
  {
    headers: {
      "x-integrator-id": integratorId,
      "Content-Type": "application/json",
    },
  }
);

const route = routeResult.data.route;
const quoteId = route.quoteId; // Save this — required for status tracking
console.log("Quote ID:", quoteId);

Transaction Request Types

The route response's transactionRequest object will include a transaction_request_type field that determines how to execute the transaction. There are three types:

TypeDescription

ON_CHAIN_EXECUTION

Standard on-chain transaction (EVM). Execute like any Squid transaction.

DEPOSIT_ADDRESS_CALLDATA

Deposit to the provided address with the specified calldata. Used for certain non-EVM chains.

DEPOSIT_ADDRESS_WITH_SIGNATURE

Submit a signed deposit to the provided address. Used for certain non-EVM chains.

Executing the Route

ON_CHAIN_EXECUTION (EVM Transactions)

For EVM-to-EVM Squid Intents routes where transaction_request_type is ON_CHAIN_EXECUTION, execution is the same as any Squid transaction:

DEPOSIT_ADDRESS_CALLDATA & DEPOSIT_ADDRESS_WITH_SIGNATURE

For certain chains, Squid Intents uses a deposit address flow instead of standard on-chain execution. The transaction_request_type field will be one of:

  • "DEPOSIT_ADDRESS_CALLDATA" — submit a deposit to the provided address with the specified calldata

  • "DEPOSIT_ADDRESS_WITH_SIGNATURE" — submit a signed deposit to the provided address

Status Tracking

Status polling is required for Squid Intents. After executing a Squid Intent transaction, you must call the status API with the quoteId parameter. If quoteId is not included in the status call, the Squid Intents transaction will be refunded to the source chain.

Getting the Quote ID

The quoteId is returned at the top level of the route response:

Polling for Status

Refund Behavior

When a Squid Intent transaction fails, funds are automatically refunded on the source chain. Refunds typically complete within ~15 minutes.

  • Funds are transferred from the msg.sender on the source chain

  • Refunds are sent to the order.fromAddress, which corresponds to the fromAddress in the route request

  • This ensures refunds go to the actual user even if the transaction was initiated through a smart contract

Squid Intents Limitations

  • Bitcoin and Solana support is coming soon

Last updated