Why 1inch API integration breaks under load
A swap via 1inch API is not a single request but a chain: get a quote, build a route, sign the transaction, send it to the network. The break happens at any step, and most often at the third.
Seconds pass between the aggregator's response and the signature, during which the pools have already changed: if slippage tolerance is not provided or is hardcoded, the contract will reject the trade based on the minimum received amount. The user pays for gas and sees a rejection.
The second point is the route itself. During peak hours, liquidity is spread across dozens of pools, and some paths simply cannot be assembled: the aggregator responds that there is no route, or returns an option with a price that cannot be shown to the user.
Load on the exchange adds timeouts and rate limits — the interface displays an aggregator error even though liquidity exists on the market.
The third point is a stale quote. If the application does not re-request the price before signing and does not verify it against the actual state of the pools, the transaction goes out with data that is ten seconds old.
This is where the main share of swap failures settles: during quiet hours everything goes smoothly, but at peak the failure rate grows severalfold — losses fall exactly in the period when turnover is at its maximum.
Let's break down how this is closed — from re-requesting the quote to a backup route in case the primary one fails.
What liquidity aggregation delivers: the effect in metrics
One pool is one rate and one volume ceiling: a large order moves the price inside it and loses on slippage. Liquidity aggregation splits the order into parts and routes them across several sources, picking up counter-order remainders along the way.
1inch returns a ready route together with the expected result — the rate improvement appears without manually sorting through venues and without custom quote comparison logic.
The effect of implementation is visible in exchange metrics. Share of successful swaps — how many orders reached execution rather than dropping out at calculation.
Deviation of the actual rate from the one shown to the user — losses between trade confirmation and inclusion in a block. Share of cases where, when liquidity leaves the primary pool, the route rebuilt to the backup one.
Resilience during peak hours is a separate metric. On sharp market movement, a single pool becomes skewed, and some trades fail on slippage.
This is the class of failures that is almost completely closed: splitting the order into short steps, recalculating the route before sending, and a fallback path reduce dependence on the drawdown of one source.
In practice, the share of executed orders grows, the number of retries and manual investigations falls, and the rate for the user behaves predictably both in a calm and in a volatile window. We capture metrics before and after — we confirm the effect with data, not with a promise.
1inch API operating modes: direct call, proxy, batches
The call mode determines where secrets are stored, who is responsible for limits, and how fresh the quote reaching the user is.
A direct call to 1inch API from a decentralized application gives minimal latency, but the key goes into the client bundle, and request rate is counted by external address — during a traffic spike, some requests drop out. In practice, one of four options is chosen.
| Mode | When it is appropriate | Mode limitations |
|---|---|---|
| Direct aggregator call | Prototype, one exchange scenario, minimal latency | Secret is available in the client, no shared quota, difficult to log and debug |
| Through your own proxy | Production load, multiple interfaces, audit and shared limit needed | Plus one latency link; a custom retry and failure-control layer is required |
| Batch requests | Portfolio, screen with multiple pairs, route comparison | Partial failure and different response sizes — explicit per-item error handling is needed |
| Quote cache | Frequent interface updates without load on the aggregator | A stale price leads to slippage; recalculation before signing is mandatory |
The cache is not a separate mode but an add-on to any of them: the response is held for seconds and refreshed before transaction signing, otherwise the user confirms the route at the old price.
For batches, the behavior on partial failure is fixed in advance: an unavailable route must not bring down the entire screen.
Choosing a mode is a trade-off between latency, control over secrets, and fault tolerance. Next, we will break down how these modes combine in a single application without duplicating logic.
Implementation order: from audit to handover of procedures
The implementation order is structured so that exchange works on real pairs before the first trade with real funds enters the code. Each stage ends with a verifiable artifact — a diagram, configuration, load report — rather than a verbal “done”.
- Integration audit. We break down where exchange is currently executed, which pairs and volumes go through, who manages keys and limits, and how failures are handled. The output is a map of current flows and a list of places where 1inch replaces existing logic or sits alongside it.
- Flow diagram. We fix the request path: obtaining a quote, checking slippage tolerance, its lifetime, signing, and sending to the network. We separately mark failure points — aggregator response timeout, rejected trade, rate divergence between calculation and execution.
- Configuration. We connect the aggregator's methods, cover error handling, retries, and protection against duplicate operations. Tolerances and quote parameters are moved into configuration, not code, so they can be changed without releasing a new build.
- Load testing. We run parallel quote and trade requests, observe behavior when the aggregator is unavailable, and degradation under peak. The goal is predictable response time and a clear failure queue, not a record in the report.
- Exchange acceptance. We verify actual routes and output amounts, conduct small trades on the mainnet, and check refunds on failure at any step.
- Handover of procedures. We hand over diagrams, configurations, metrics, and rollback instructions: the on-call shift must understand what to do when trades are rejected and how to return to the previous exchange route.
What remains with you: configurations, diagrams, procedures
Integration with 1inch is not only routing code: support lives in settings, quotas, and procedures. That is why we hand over a package that your team can use to develop the exchange and respond to failures on its own, without contacting us.
- Exchange configurations. Parameters moved out of code: list of networks and tokens, slippage thresholds, route priority, fee recipient addresses. Changed without rebuilding the application.
- Interaction diagrams. A diagram of the request path from interface to aggregator and back: who signs the trade, where the final price is calculated, and at which points a failure is visible first.
- Request limits. A table of quotas for each external source with headroom for peak load, retry rules, and a description of behavior when the quota is exhausted.
- Operational procedures. What to check when adding a new network or token, how to update reference data, a release checklist for changes, and the approval procedure for edits.
- Failure alerts. Thresholds and recipients: growth in the share of failed routes, quote divergence, response latency above acceptable, background jobs stopping.
- Recovery plan. Procedure for router degradation: switching to a backup source, manual trade confirmation mode, criteria for returning to normal operation.
- Accesses and documentation. Roles in panels, keys with limited permissions, their rotation procedure, and brief instructions for the on-call engineer.
Case study: how swaps stopped breaking during peak hours
What it was like before integration
This integration case started with a token exchange service where the user swaps an asset in one click.
The route was built through a single liquidity pool, and during peak hours this was not enough: when network activity grew, the price moved between showing the quote and confirming the trade.
The result: the share of successful swaps fell to 76–78%, and quote response time stretched to 10–12 seconds; some users left without waiting for the exchange.
What was changed and how it works
We connected the 1inch aggregator: it splits the exchange across several pools and selects the path with the best final rate rather than fixing a single source.
We recalculate the quote with a short lifetime and refresh it before sending the trade — the slippage limit is calculated from the current price, not from the one the user saw.
In case an individual source is unavailable, we left a backup route: the exchange does not stop if a pool does not respond or responds slowly.
Implementation results
The share of successful swaps during peak intervals grew to 97–98%, exchange response time dropped to 2–3 seconds and stopped growing under load.
Slippage-related rejections left the top causes of failed trades — their place was taken by user errors: insufficient funds and rejected signature.
Load runs during peak hours showed the same picture as during calm windows — the service's behavior stopped depending on the time of day.
What to do if the aggregator is already integrated but quotes diverge
Divergence is almost always born not inside the aggregator but at the point where you compare numbers. The quote is calculated for one state of the pools, while the signature goes out in the next block, and the route between these moments is rebuilt anew.
Plus, the quote usually does not include the aggregator's own fee and execution cost, so when reconciling “calculator versus wallet balance,” there will always be divergence, even on a correctly functioning integration.
Route diagnostics begin with breaking down how the volume was split. Look at which liquidity sources the split went through, what share went to each pool, and whether the breakdown changed between two identical requests in a row.
If the route is different every time for the same volume, you are catching liquidity noise and recording not a breakdown but normal rebuilding — then it is the reconciliation logic that needs fixing, not the call itself.
Checking trade profitability comes down to three numbers: minimum received amount, price impact, and the set slippage tolerance.
A frequent cause of an apparent divergence is comparing amounts in tokens with different precision or without accounting for wrapped ether: exchange through the native token and through its wrapper produce different output results with the same route.
The signature does not match the calculation when the transaction has expired, the one-time allowance nonce has been reused, the network ID differs, or the recipient is set to the wrong address.
Another source is that the quote was requested from one router branch, while the exchange is assembled for another: the parameters are comparable, but the contract executes differently. It is treated by reconciling both responses before signing, not by retrying blindly.
Targeted rebuilding of the logic looks like this: the quote is requested immediately before signing, the window between them is limited, the minimum amount is rechecked after receiving the transaction body, and the actual result is written to monitoring together with the calculated one. Then divergence stops being a mystery and arrives as an event with a known cause.
Common technical questions about exchange integration
When migrating to 1inch API, clients check roughly the same things: whether the new layer will break already working contracts, what happens on a failed exchange, and how access is set up. Below are answers to what most often comes up during evaluation.
Can a direct call to the exchange contract be replaced with an aggregator?
Yes, and usually that is where they start. A direct call gives the best price within one pool, while the aggregator splits the amount across several routes and aggregates the total across all liquidity sources. There is no need to rewrite the service logic — only the transaction preparation layer changes.
What happens if the exchange fails?
The transaction is rejected before funds are debited: the price moved beyond the slippage boundary or the route lifetime expired. The response includes a reason code by which these cases are distinguishable. The retry is built on a fresh calculation, not on a saved one.
How are access and keys issued?
The key is issued for a specific service with a restriction by request source and a daily request limit, and can be revoked without stopping the application. Wallet private keys do not enter this scope — signing remains on your side.
How can I verify that the route was built correctly?
Before signing, a calculation is requested: expected output amount, list of sources, and minimum amount taking slippage into account. The values are checked against your boundary, and only then does the transaction go to the network. The calculation and execution fact are logged — divergence is visible immediately.
Will the integration affect existing contracts?
No, if the exchange is moved into a separate layer: old contracts continue to work through the same interfaces. Migration is done gradually — first on part of the volume, with rollback to a direct call via a single setting.
Let's discuss your task: we will come back with an estimate and plan
To make the integration estimate substantive rather than “based on feelings,” three things are enough at the start: which network and which token pairs your product serves, how the transaction is currently signed and sent, and what access restrictions the node has.
If part is already implemented, send the current exchange code with the aggregator: we will review it and suggest what to reuse and what to rewrite.
In response, we will return an estimate of the scope of work, a solution diagram with explicit failure points, and a stage plan with implementation timelines.
We will separately list everything that will go to you during documentation handover — so that support can be run by your own team, without us.
- Breakdown of your exchange scenario: routes, slippage, minimum acceptable output per trade.
- Solution diagram: where the aggregator sits, how failures and retries are handled.
- Integration estimate by stages — by scope of work, not by a single averaged figure.
- Work plan with implementation timelines and a checkpoint where the result is visible.
- List of accesses and keys needed from you, with requirements for their storage and rotation.
- Documentation package: configurations, method descriptions, and procedures for the on-call shift.
To discuss the task, an email describing the scenario and current state is enough. We will come back with an estimate and plan — and if the integration is already running, we will start with its audit: it is often faster to refine the exchange than to assemble it anew.