FAQ

TL;DR CORS errors happen because the 0x API enforces strict security policies. Avoid making API calls directly from the browser to prevent CORS issues and exposing your API keys. Instead, use a backend server, serverless functions, or a full-stack framework.

Error Message You might see an error like this:

1
http://localhost:3000 has been blocked by CORS policy: Request header field 0x-version is not allowed by Access-Control-Allow-Headers in preflight response.

Explanation
This error occurs because browsers block requests with custom headers (e.g., 0x-version) unless explicitly allowed by the server. Making API calls from a browser is not recommended because it can expose your API keys.

Recommended Solutions

1. Use a Backend Server — Proxy API calls through a backend server and handle API keys securely (e.g., axios in Node.js or requests in Python).
2. Serverless Functions — Use AWS Lambda, Vercel Functions, or Netlify Functions.
3. Full-Stack Framework — Implement backend logic in Next.js or Remix.

See Handling API issues and error codes for a full list of common 0x issue types and error codes and how to resolve them.

If your 0x quote is reverting, besides the standard revert issues related to ETH transactions, check the following:

• Are allowances properly set for the user to trade the sellToken?
• Does the user have enough sellToken balance to execute the swap?
• Do users have enough to pay the gas?
• The slippage tolerance may be too low if the liquidity is very shallow for the token the user is trying to swap. Read this guide.
• Did the RFQ Quote expire? RFQ quotes are typically valid for ~60s on mainnet. See the RFQ expiry accordion below.

For more details, see Troubleshooting.

RFQ quotes from Market Makers are only valid for a short period (roughly 60s on mainnet).

Two ways to check:

• Use the Tenderly debugger on the transaction; look for getOTCOrderInfo in the trace and inspect expiryAndNonce.
• You may need to reach out to 0x support to help decode expiryAndNonce.

Best practice: refresh quotes about every 30s to prevent RFQ expiry. See Matcha.xyz for an example.

Some subset of 0x orders may revert (not fill) while the overall transaction succeeds. This is expected: due to timing/pricing, some orders may be filled or expired before a user attempts to fill. The protocol uses fallback orders to compensate, resulting in a successful transaction even though internal order reverts occurred.

Passing a taker lets 0x API provide a bespoke quote and catch revert issues:

• Estimate gas for taker to execute the quote.
• If successful, gas in the quote reflects an accurate execution estimate.
• If not, a gas estimation error hints at execution issues for that taker.

TL;DR Pass taker to validate quotes and avoid many revert cases.

Verify that the API request is formatted properly. If the issue persists,

.

The buy token is not authorized for trade due to legal restrictions.

An internal server error occurred.

• Check that the API request is formatted properly.
• Check 0x system status.
• If the issue persists, contact support.

The API will return liquidityAvailable=false and omit other response params if there isn’t enough liquidity available for the requested quote.

Use the getSources endpoint.

Use the getSources endpoint.

Use the getChains endpoint to get a list of supported chains for Swap.

We offer two transparent, flexible tiers for Web3 businesses of all sizes. You can get started here. If you are a high-volume app or have a unique business model, please contact us to discuss a custom plan.

0x takes an on-chain fee on swaps for select tokens for teams on the Standard tier. This fee is charged on-chain to your users during the transaction. In cases where we charge a fee, we return the value in the API response as zeroExFee. See the Swap API reference for details.

Swap API samples each liquidity source and adjusts for gas consumption (using your specified gas price, or a fast default) and any associated fees. It evaluates different compositions of sources to select the best set of orders, and also creates fallback orders to ensure executability.

Example: Curve’s nominal price may look best, but after factoring gas * gasPrice and fees, it may not be optimal.

0x supports all tokens by default except those blocked for compliance reasons.

If you’d like to trade a custom token, you’ll need to create liquidity by deploying a pool on an AMM the API sources (e.g., Uniswap, SushiSwap, Curve).

MEV protection applies to RFQ orders, which are filled privately and atomically to prevent sandwiching/front-running. It does not apply to AMM trades, which execute on public mempools and are subject to typical MEV risks.

You can collect affiliate fees or trade surplus. Read the full guide: monetizing your swap integration.

If swapFeeRecipient, swapFeeBps, and swapFeeToken are set, the response includes fees.integratorFee.amount which you can display to users.

amount = (swapFeeBps / 10000) * sellAmount  // in sellToken base units

Example for 1% of 100 USDC:

• sellToken=0xA0b8…eB48 (USDC)
• swapFeeToken=0xA0b8…eB48
• sellAmount=100000000 (USDC has 6 decimals)
• swapFeeBps=100

Fee amount = 1000000 = 1 USDC.

See the guide: monetization. In API v2, you can take fees on buyToken or sellToken.

Available to select integrators on a custom pricing plan. Contact support. See the monetization guide.

0x Swap API supports two allowance methods: AllowanceHolder (recommended) and Permit2 (advanced).

AllowanceHolder (Recommended)
Better UX, lower gas, simpler integration, and safe defaults. Great for aggregators, teams upgrading from Swap v1, and advanced wallets (multisigs/smart accounts).

Endpoints:

• /swap/allowance-holder/price
• /swap/allowance-holder/quote

Allowance target is returned in issues.allowance.spender or allowanceTarget.

Chain-specific AllowanceHolder addresses (verify with official docs before hardcoding):

• 0x0000000000001fF3684f28c67538d4D072C22734 — Cancun hardfork chains (Ethereum Mainnet, Arbitrum, Avalanche, Base, Berachain, Blast, BSC, Ink, Linea, Mode, Monad, Optimism, Plasma, Polygon, Scroll, Sonic, Unichain, World Chain)
• 0x0000000000005E88410CcDFaDe4a5EfaE4b49562 — Shanghai hardfork chains (Mantle)

Permit2 (Advanced Only)
Enables time-limited/granular approvals but requires a double-signature flow. If you use Permit2, set allowances on Permit2 only — never on the Settler (funds may be lost).

Endpoints:

• /swap/permit2/price
• /swap/permit2/quote

Permit2 address (all chains): 0x000000000022D473030F116dDEE9F6B43aC78BA3

Read more about the contracts here.

Depends on UX and integration type:

• AllowanceHolder: single-signature UX, consistent across sources, similar to Swap v1.

• Permit2: universal approvals and time-limited/granular allowances; requires an extra signature.

The AllowanceHolder contract.

Ethereum signatures: r, s, v, ordered as r, s, v, where:

• r < secp256k1n
• s < (secp256k1n / 2 + 1)
• v is 0 or 1; on EVM encode as 27 + v (27 or 28)

Pack to 65 bytes: bytes 0–31 = r, 32–63 = s, 64 = v.

Gas is the fee required to conduct a transaction on Ethereum, paid in ETH and denominated in Gwei (1 ETH = 1,000,000,000 Gwei).

It’s a standardized representation of native tokens (e.g., ETH, BNB, POL) which don’t have contract addresses like ERC-20s.

On Mantle: $MNT is an exception with contract address 0xdeaddeaddeaddeaddeaddeaddeaddeaddead0000 on Mantle EVM (not applicable to wrapped/bridged MNT). See Handling native tokens with 0x Swap API.

Yes. All buyAmount values are in the token’s base units.

• 18 decimals (e.g., WETH, DAI): 1000000000000000000 = 1.0
• 6 decimals (e.g., USDC): 1000000 = 1.0

Useful helpers:

• ethers.js → formatUnits
• viem → formatUnits

No — in v2 only sellAmount is supported for more deterministic behavior and broader liquidity support.

No — taker is required in v2 for /quote. It enables us to return calldata and identify issues that would cause failures.

The Settler contract can be redeployed; the to target address will therefore change. See: current/future Settler addresses.

Contact 0x to discuss a solution that best suits your use case.

When applicable, the fee is returned as zeroExFee in quotes. You are responsible for showing the amount and token to users. See the Pricing Page and

.

Not currently, but we’re exploring this feature.

Options:

• Copy from Etherscan (Contract tab → ABI).
• Use the Etherscan API.
• Fetch from the token’s GitHub repo if available.

• Import erc20Abi from

  viem

  .

Depends on your use case:

• 0x Trade Analytics API — historical analysis, usage tracking, reporting.
• 0x-parser — TypeScript library for decoding real-time 0x transaction logs.

See the 0x transaction data guide.

Not directly via onchain data alone. While all 0x API trades settle through the Settler contract, transactions don’t include a unique tag that explicitly ties them to the API.

• Use the 0x Trade Analytics API.
• Enable onchain tagging in the 0x Dashboard (Settings → “Enable onchain tagging”).

• You can monitor the Settler contract, but it includes non-API transactions.
• For aggregated usage insights, reach out and share your use case.

Use the getSources endpoint.

See the full list of supported chains

Short answer:

Gasless API provides a gasless experience at two points of the trade flow where users normally pay gas:

• Gasless approvals work only for tokens listed in our Gasless Approval Token endpoint (tokens that support EIP-2612).
• Gasless swaps work for selling any non-native token (ERC-20 or similar).

What doesn’t work:

You can’t use Gasless API to sell a chain’s native coin (e.g., ETH on Mainnet, POL on Polygon). Native coins aren’t ERC-20s, so they lack transferFrom which the relay system uses. Use the Swap API instead (user pays gas in the native token) or have users wrap the coin (e.g., ETH → WETH).

Work-arounds for tokens not supported by Gasless API:

1. Use the regular Swap API — the user pays gas in the native coin.
2. Wrap the coin first (e.g., ETH → WETH), then use Gasless API.

Use the

(user pays gas in the native token), or have users wrap the native coin first (e.g., ETH → WETH), then use Gasless API.

It varies by chain, size, and gas conditions. If the amount is too small, the API returns an error with the estimated minimum. As a guideline, set a minimum of about $10 on Mainnet and$1 on other chains.

Both enable gasless-like UX, but they serve different purposes.

In short: Permit (EIP-2612) is an ERC-20 extension enabling gasless approvals via an EIP-712 signature — no on-chain tx — but only for tokens that implement EIP-2612. Many older tokens (e.g., WETH) don’t, so they still need a regular approve().

Permit2 (by Uniswap Labs) is a universal approval contract for any ERC-20. Users first do a standard gasful approve() to Permit2, then future moves can be authorized via EIP-712 signatures (gasless for subsequent swaps). This is useful when tokens don’t support permit() but you want a consistent meta-tx flow. Permit2 is deployed at 0x000000000022D473030F116dDEE9F6B43aC78BA3 on major chains.

0x covers the gas fee up front. The cost is wrapped into the trade and paid in the token the user is trading. Applications may choose to sponsor transactions; in that case they pay 0x directly and users are not billed on chain.

You have full flexibility on the fees you collect on trades.

Include these parameters when making a Gasless API request:

• swapFeeRecipient — Wallet address to receive trading fees.
• swapFeeBps — Fee in basis points (0–1000; 1000 Bps = 10%).
• swapFeeToken — Contract address of the token to receive fees (must be buyToken or sellToken).

$
https://api.0x.org/gasless/quote                          # Request a firm quote
$
?chainId=1                                                # Ethereum Mainnet
$
&sellToken=0x6B175474E89094C44Da98b954EedeAC495271d0F     # Sell DAI
$
&sellAmount=4000000000000000000000                        # Sell amount: 4000 (18 decimals)
$
&buyToken=0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE      # Buy ETH
$
&taker=$USER_TAKER_ADDRESS                                # Trader address
$
&swapFeeRecipient=$INTEGRATOR_WALLET_ADDRESS              # Recipient of affiliate fees
$
&swapFeeBps=100                                           # 1% fee (100 bps)
$
&swapFeeToken=0x6B175474E89094C44Da98b954EedeAC495271d0F  # Take fee in sellToken (DAI)
$
--header '0x-api-key: [API_KEY]'                          # Your API key
$
--header '0x-version: v2'                                 # API version

Gasless approvals are supported only for tokens listed in the gasless approval token endpoint.

Check the response from /gasless/quote,

• If issues.allowance is not null, an allowance approval is required.

• If approval is not null, a gasless approval is possible.

Gasless approvals and gasless swap are bundled in the same transaction, but each requires a signature for its EIP-712 object. You can design the UI so it feels like a single step to the user.

See the flow charts

.

Read more about

.

The Trade Analytics API gives integrators easy access to the history of trades initiated through 0x APIs and settled on 0x Smart Contracts. This API offers comprehensive transaction records, providing useful insights into user trading behavior.

The Trade Analytics API will only return data for the app associated with the API key that makes the request. While all trading data is publicly available onchain, the Trade Analytics API provides a streamlined, well formatted data for the specific app making the request.

The data accessed through the API is deemed final 48 hours after a trade is completed. This delay allows time for the data pipeline to capture all relevant information, including fees from proxy contracts and updated USD prices from Coingecko.

To ensure that your trading data is up to date, we recommend that you fetch and update data from the preceding 2 days in addition to the current day.

Data is updated roughly every 15 minutes. While generally reliable, data from these updates can sometimes be missing or incomplete, especially if they have a dependency on external sources such as token USD price providers. Each trade data is considered final 48 hours after it’s mined onchain – this enables us to address any gaps from earlier updates, ensuring data accuracy.

We don’t recommend using this API for use cases that require real time updates. If you’re interested in such data, please submit a feature request.

It’s a common question — and the short answer is: not directly via onchain data alone.

While all 0x API trades are settled through the 0x Settler smart contract, these transactions don’t include a unique tag or flag that explicitly ties them to the API.

That said, there are a few ways to approach attribution, depending on what you’re trying to track:

🔍 If you’re trying to track your own app’s activity

• The 0x Trade Analytics API is the best place to start. It allows you to query detailed trade data associated with your API key.
• Enable onchain tagging. In your 0x Dashboard, go to your app’s Settings and toggle on “Enable onchain tagging.” This makes it easier to filter and trace your transactions onchain later.

🌍 If you’re trying to detect any and all transactions routed via the 0x API

• You can monitor the 0x Settler contract for activity, but this includes all transactions — not just those initiated via the 0x API.
• Currently, there is no canonical event that maps directly to “this came from the Swap API,” but we’re exploring ways to make API attribution more accessible in the future.
• If you’re interested in aggregated Swap API usage data, we may be able to share insights or internal tools depending on your use case. Reach out to us — we’d love to hear more about what you’re trying to build.

We understand attribution is an important use case, whether you’re tracking your own usage or seeking broader ecosystem insights. Don’t hesitate to contact us to discuss how we can best support you.

Trade Analytics API is best for historical analysis and business intelligence. Provides comprehensive trade data including volumes, fees, and USD values.

0x-parser is a best for real-time transaction data and displaying final swap amounts immediately after settlement.

Read more about accessing 0x transaction data here.

For now we only support one user per team account, but we will add support for multiple users in the coming weeks.

An app is a self-contained unit for each application that you’re building. You can set up multiple apps, each with unique API keys and configurations, on the 0x Dashboard.

Yes. See

. Check out our bounty program .

Create an account on the 0x Dashboard to get an API key and start building for free. You can also review plans and contact our team for custom needs.

Thank you for your interest in providing liquidity to the 0x ecosystem. Please refer to the “Liquidity Integrations” tab.