Skip to main content

1inch API troubleshooting

Written by Bruno

Quick links:


Rate limits and monthly quota

The Free plan allows up to 60 requests per minute. Current plan limits and higher-tier options are listed on the pricing page.

Every plan has two separate limits: a rate limit (requests per second) and a monthly call quota. When you exceed either limit, the request is blocked with a 429 response. There are no overage charges (see the Pricing and subscriptions FAQ).

  • RPS limit hit: the response carries an X-RateLimit-Retry-After header. Slow down and retry.

  • Monthly quota used up: requests stay blocked until the next billing cycle. You can top up with extra requests or upgrade your plan.

Authenticated responses include three headers to track your quota:

  • X-SubscriptionLimit-Limit: the monthly call quota of the product group you called, top-ups included.

  • X-SubscriptionLimit-Remaining: the approximate number of calls remaining in the current billing period.

  • X-SubscriptionLimit-Reset: the unix timestamp (seconds) when the billing period renews.

The values refresh within about 35-50 seconds and can briefly understate your usage, but never overstate it. Quotas are tracked per product group, so endpoints in the same product report the same numbers. The headers are absent on unauthenticated responses and on plans with an unlimited quota. You can also check usage in the portal under Observability -> Usage.


Troubleshooting "Insufficient Liquidity" error

This error can occur for a number of reasons:

  • The liquidity pool has not been queried - make sure one of the aggregated sources has at least 10k of a connector token listed below.

  • If you're getting a quote, please make sure to take into account the decimals of the token. Do not include decimal places in the "from token amount". The API returns the number of decimal places the token supports when calling /quote or /swap

  • There's an error in the server and is unable to find a path, this may require contacting the 1inch support team for more investigation.


Troubleshooting "Cannot Estimate"

This error occurs when the eth_estimateGas RPC call throws an error. There are many reasons why the RPC request may result in an error, and they all mean the transaction is guaranteed to fail. This is a protection, so a transaction is not broadcast that's certain to fail. To find the precise error, disableEstimate=true query parameter can be used with the swap endpoint. The resulting calldata can then be used with eth_estimateGas request locally for the precise revert reason. The transaction can also be simulated with a platform like tenderly or phalcon for a better look at the transaction trace.

Some common reason why a transaction may fail:

  • A token has a fee on transfer or swap and the slippage tolerance needs to be increased

  • A token has a fee on transfer and the fee and referrer parameter is set causing the transaction to always fail

  • The rate has expired and changed in the latest block.


Troubleshooting insufficient allowance / balance

In the case of one of these errors, you may not have a token approval or you're missing the token balance. To do a token approval, you can use the API to generate the calldata to approve the token to the 1inch router.


What are the "parts" parameters?

The parts parameters control how finely the router is allowed to split an order, applying to different levels of the route. It is composed of 3 components.

  • mainRouteParts

  • virtualParts

  • parts

Only mainRouteParts and parts may be configured. Each controls a different level of how a route can be split. The mainRouteParts controls the initial split and can be seen on the UI at https://1inch.com/swap. In the following example the initial ETH is split 65% going to USDT and the remaining 35% going directly to LINK.


virtualParts control the splits that happen inside a route, for example, the lower route contains a USDT -> USDC execution that is internally split between 2 liquidity sources, Ekubo and Fluid_dex_T1. Those allocations are virtual parts and represent the router dividing one section of the route across multiple underlying executions. Although not configurable, it is a way to represent the router dividing one section of the route across multiple underlying executions.
​
The parts parameter is the overall limit on the number of individual parts the router can use. A part represents an individual token pair routing allocation. This includes allocations created by the initial main-route split and allocations created by internal virtual splits.
​


How can I limit the liquidity sources in the query?

To limit the liquidity sources to a query, select them using the "protocols" parameter as a CSV list of liquidity sources.

https://api.1inch.com/swap/v6.1/{chain}/quote?protocols=UNISWAP_V3,UNISWAP_V2&...

Debugging with X-Request-Id

Every API response includes an X-Request-Id header that uniquely identifies your request. When you contact support about a failed request, include the X-Request-Id value together with the full request URL and the timestamp. It lets us find your exact request in our logs.

Still have questions?

Reach out to the community on https://discord.gg/AfQRzPyREm or the live chat.

Did this answer your question?