LI.FI's API for Agentic Commerce: How Cross-Chain AI Execution Works

AI agents are becoming economic actors. They monitor markets, allocate budgets, route payments, and settle transactions without waiting for a human to approve each step. The infrastructure challenge this creates is significant: blockchains were built for human-initiated transactions, not autonomous systems running at machine speed across dozens of chains. LI.FI's API for agentic commerce is one of the more concrete attempts to close that gap.

This post explains what the API actually does, how the integration model works, where it fits into the broader agentic commerce stack, and what developers building autonomous onchain workflows should understand before adding it to their agent.

Agentic commerce refers to commercial activity initiated and settled by autonomous software agents rather than humans. The agent receives a goal, reasons over available options, and executes transactions to accomplish it, including cross-chain token swaps, bridge transfers, DeFi deposits, and API payments.

IBM's research on AI agents and stablecoin adoption clearly frames this shift: stablecoin micropayments become viable in agentic contexts because agents can pay per API call or per unit of data consumed, settling instantly with negligible fees. Legacy payment systems require human intervention and operate on a minimum-transaction economics that make sub-dollar transfers impractical.

Stablecoins are the default currency in agentic commerce for four concrete reasons. They settle in near real time. Fees are low enough for micropayments. They are natively programmable via smart contracts. And they are available 24/7 without the operational windows that characterize traditional banking rails. QED Investors' analysis of agentic payments notes that the underlying coordination challenge is not payments infrastructure alone but the interoperability layer sitting above it, connecting agents to the specific chains, tokens, and protocols where liquidity and activity actually live.

That interoperability problem is where LI.FI operates.

LI.FI already powered cross-chain swaps and bridging for wallets, DeFi protocols, and developer applications. The agentic commerce release repackages that infrastructure for autonomous systems with three additions: an MCP server, standardized agent skills published to major agent directories, and AI-first documentation designed for machine parsing rather than human reading.

At its core, the API aggregates 27 bridges and 31 exchanges across 58 blockchains, including EVM chains, Solana, Bitcoin, and SUI. The routing engine compares available paths and surfaces the best option for a given swap or bridge request. This is the same infrastructure LI.FI has been offered to developers for some time. What changed is how agents access it.

The most practically significant addition is the hosted Model Context Protocol (MCP) server at https://mcp.li.quest/mcp. MCP is a standardized protocol that lets AI agents discover and call tools directly without constructing raw HTTP requests. For AI agents running inside MCP-compatible hosts like Claude, Cursor, or Windsurf, the MCP server exposes all of LI.FI's core endpoints as discoverable, typed functions.

The server covers 15 or more structured tools across six categories: token information, chain information, quote and swap execution, discovery and routing, gas queries, and balance and allowance checks. An agent can call get-quote to price a swap, get-chains to enumerate supported networks, and get-status to monitor a transfer in progress, all through structured inputs and outputs that require no manual HTTP construction.

For agents running outside MCP-compatible environments, the REST API remains the recommended integration path. It requires only HTTP calls with no additional dependencies.

The LI.FI agent integration documentation introduces what it calls a "five-call recipe": a minimal, ordered sequence of API calls covering the complete swap and bridge workflow from discovery through confirmation. The five core endpoints are:

1. Get a Quote (GET /v1/quote) returns a transaction object ready for signing, given a source chain, destination chain, token pair, amount, and sender address. The response includes a transactionRequest field the agent can sign and broadcast directly.

2. Check Transfer Status (GET /v1/status) takes a transaction hash and returns a status field with one of four values: NOT_FOUND, PENDING, DONE, or FAILED. Agents should poll this endpoint every 10 to 30 seconds and use the substatus field for granular progress information, including whether a partial completion or refund occurred.

3. List Supported Chains (GET /v1/chains) returns all chains LI.FI supports, with optional filtering by chain type (EVM, SVM, UTXO, MVM).

4. List Supported Tokens (GET /v1/tokens) returns tokens available on specified chains, along with addresses, symbols, and decimal precision.

5. List Available Tools (GET /v1/tools) returns bridges and DEX exchanges available for routing, including which chains each supports.

This five-endpoint surface covers the majority of agent use cases without requiring knowledge of the full API specification. For more complex or multi-step routing, the /advanced/routes endpoint provides multiple path options rather than a single best quote.

Beyond direct API and MCP access, LI.FI has published pre-built agent skills to ClawdHub, skills.sh, and Playbooks. These allow agent developers to add cross-chain execution as a native capability without writing integration code. A Playbooks-compatible agent, for instance, can integrate cross-chain execution in minutes using the official LI.FI skill rather than building from an API call.

Rate limits matter significantly for autonomous agents because polling and high-frequency execution create request volumes that human-driven integrations rarely approach.

Without an API key, LI.FI allows 200 requests per 2-hour window. With an API key, the limit rises to 200 requests per minute. For agents polling transfer status every 15 seconds across multiple concurrent workflows, or agents executing treasury operations at volume, the unauthenticated tier will create bottlenecks quickly. The authenticated tier at 200 requests per minute is the practical floor for production agentic use cases.

LI.FI's documentation also provides error playbooks mapping every HTTP status code and API error to a cause, retry eligibility, required fix, and user-facing message template. For agentic systems where errors must be handled programmatically rather than surfaced to a human for review, this is a useful resource that goes further than most API documentation.

Understanding LI.FI's API for agentic commerce requires understanding what sits below it. Aggregating bridges and exchanges handles routing across existing infrastructure, but the stablecoin liquidity layer those bridges draw on is equally important to execution quality.

Orium's research on B2B payments and agentic AI identifies the core challenge: autonomous agents need programmable financial infrastructure with hard-coded safeguards, not just access to APIs. That means the quality of outcomes for an agent using LI.FI depends on the liquidity available at the time of execution, the depth of the order book on the destination chain, and whether the routing engine-selected path has sufficient capacity for the transaction size.

This is where stablecoin infrastructure providers sit in the stack. Rather than routing through bridge aggregators after the fact, platforms like Eco build the execution layer from the intent up. Eco's programmable execution infrastructure is designed specifically for encoding conditional, composable stablecoin flows that respond to market conditions in real time according to developer-specified rules. Where LI.FI aggregates existing bridges, Eco's intent-based architecture transforms desired outcomes into guaranteed execution through cryptographic settlement.

For developers evaluating how to stack these tools, the distinction matters. LI.FI's API is a strong routing and aggregation layer. Real-time money movement built on intent-based execution with cryptographic guarantees addresses a different layer of the same infrastructure problem: what happens when you need deterministic settlement rather than best-available routing.

Coincub's analysis of crypto AI agents in 2026 describes the autonomous treasury management pattern: agents monitor yield opportunities across chains and rebalance positions within programmed risk parameters without human approval loops. For a company holding USDC across Ethereum, Arbitrum, and Base, an agent could monitor rate differentials, calculate net yield after bridge costs and slippage, and execute rebalancing transactions during favorable windows.

LI.FI's /quote endpoint provides the cost and execution data the agent needs to evaluate whether a rebalancing action is worth executing. The status polling loop then tracks completion.

The stablecoin liquidity layer supporting these operations needs to provide consistent depth across the chains in play. Eco's shared stablecoin liquidity layer is designed for exactly this scenario, enabling solver competition that keeps execution costs low and prevents individual agents from exhausting available liquidity on frequently trafficked routes.

The x402 protocol pattern, described in FinTech Weekly's analysis of agentic micropayments, allows agents to pay for API access per request using stablecoins, eliminating the need for subscription accounts and billing cycles. An AI agent needing weather data for a routing decision can call the data endpoint, receive a 402 payment required response, submit a stablecoin proof of payment, and receive the data in a single transaction.

For these machine-to-machine payment flows, cross-chain token availability matters. An agent that holds assets on Optimism but needs to pay a service accepting Base USDC requires a swap and bridge operation before the payment can complete. LI.FI's API for AI agent cross-chain execution covers this case directly.

An agent executing DeFi strategies needs to move capital from where it currently sits to where the yield opportunity exists, and back out when the position closes. This might involve swapping USDT to USDC, bridging from Ethereum to Arbitrum, depositing into a yield vault, monitoring the position, and exiting when conditions change.

The LI.FI five-call recipe combined with status polling and error recovery handles the execution mechanics of this workflow. The /advanced/routes endpoint provides multiple paths for the agent to evaluate execution quality, rather than accepting a single recommended path.

Eco Routes V2 expanded this workflow to non-EVM chains through chain-agnostic encoding, enabling agents to move between EVM and non-EVM ecosystems with a single integration rather than managing separate bridge protocols for each

chain type.

When assessing LI.FI's API for agentic commerce against alternatives, a few considerations stand out:

Authentication is not optional at production volumes. The unauthenticated 200-requests-per-2-hours limit is appropriate for testing but insufficient for any agent running continuous status polling. Request an API key before building production workflows.

The MCP server reduces integration surface. For agents inside Claude, Cursor, or Windsurf, the MCP server eliminates the need to construct and parse raw HTTP calls. The structured tool interface also makes it easier to handle error states deterministically.

Partial completions require explicit handling. LI.FI's documentation covers the case where a cross-chain transfer partially completes, returning a PARTIAL substatus rather than DONE. Agents that treat any non-FAILED status as success will produce incorrect state representations. The status and recovery workflows documentation describes the correct handling logic.

The routing layer and the liquidity layer are distinct. LI.FI routes transactions through whatever bridges and exchanges are available. The depth and reliability of execution depend on underlying liquidity. For stablecoin infrastructure capable of providing atomic execution guarantees rather than best-effort routing, intent-based systems with cryptographic settlement offer a different risk profile that may be worth evaluating alongside routing aggregators.

What is LI.FI's API for agentic commerce? LI.FI's API for agentic commerce is a REST API and MCP server that gives AI agents access to cross-chain swap and bridge execution across 58 blockchains. It aggregates routing across 27 bridges and 31 exchanges and exposes the same infrastructure via a machine-readable interface designed for autonomous-agent workflows.

How does the LI.FI MCP server work? The LI.FI MCP server is a hosted Model Context Protocol server at https://mcp.li.quest/mcp. It wraps LI.FI's REST API into structured, discoverable tools that AI agents can call directly from MCP-compatible hosts like Claude, Cursor, and Windsurf. Agents call tools like get-quote or get-status with typed parameters rather than constructing raw HTTP requests.

What is the LI.FI five-call recipe? The five-call recipe is a minimal sequence of five API calls that covers the complete agent workflow: get a quote, check transfer status, list supported chains, list supported tokens, and list available routing tools. The documentation provides runnable code samples in Node.js and Python that include retry logic and exponential backoff.

What are the rate limits for AI agents using LI.FI? Without an API key, the rate limit is 200 requests per 2 hours. With an API key, the limit rises to 200 requests per minute. Agents executing high-frequency workflows or continuous status polling should use an authenticated API key to avoid throttling.

What is the difference between /quote and /advanced/routes? /quote returns a single best-route transaction ready for signing, suited for simple transfers where the agent does not need to compare options. /advanced/routes returns multiple routing options for complex or multi-step transfers, allowing the agent to apply its own selection logic.

How do AI agents handle failed or partial cross-chain transfers with LI.FI? LI.FI's status endpoint returns a status field with values NOT_FOUND, PENDING, DONE, and FAILED, along with a substatus field with granular states such as COMPLETED, PARTIAL, and REFUNDED. A PARTIAL result means the user received a different token than expected, but the transfer succeeded. A REFUNDED result means tokens were returned to the sender. Agents should handle each of these terminal states explicitly rather than treating non-FAILED responses as uniformly successful.