Uniswap API: Universal Router 2.1.1 Support Ends October 21, 2026
Uniswap API requests pinned to Universal Router 2.0 or 2.1.1 will error starting October 21, 2026. Learn how to update version headers, router allowlists and calldata decoders without mistaking API failures for pool-level changes.
Uniswap API requests that explicitly pin Universal Router 2.0 or 2.1.1 will return an API error starting October 21, 2026. This is an API support deadline, not a general shutdown of the on-chain router. Integrators should move to 2.1.2 or omit the version header, then check router-address allowlists and any calldata decoders. [1]
- Requests pinning 2.0 or 2.1.1 through the x-universal-router-version header will error from October 21, 2026. [1]
- Integrators can pin 2.1.2 or omit the header to use the API default; allowlists should accept the 2.1.2 router address on every chain in use. [1]
- Moving from 2.1.1 to 2.1.2 does not require calldata or ABI changes, but the new router address must be accepted. [1]
- For decoding 2.1.2, Uniswap lists @uniswap/universal-router-sdk 5.12.0 as the minimum SDK version. [2]
What exactly ends on October 21, 2026?
The deadline applies to Uniswap API requests that explicitly pin Universal Router 2.0 or 2.1.1 with the x-universal-router-version header. [1] The notice says those requests will cause an API error beginning on the stated date. It does not identify an HTTP status code or a cutoff time or time zone, so teams should not assume details that the notice does not provide. [1]
This is a version-specific API support change. It is not a statement that Uniswap pools are ending, and it does not describe a general shutdown of direct on-chain use of a router contract. The notice does not establish a change in pool liquidity, trading volume or LP returns. [1] Treat API reliability and pool-performance reporting as separate operational concerns.
What should integrators change based on their current version?
First, find every place the integration sets the version header. The required migration depends on the pinned version and on whether the application checks router addresses or parses returned calldata.
If the integration pins 2.1.1
Change the header value to 2.1.2, or remove the header if the integration does not need to pin a version. Uniswap says a move from 2.1.1 to 2.1.2 requires no calldata or ABI changes. Applications and wallets that allowlist router addresses should still accept the 2.1.2 address for each chain they use. [1]
Before: x-universal-router-version: 2.1.1
After, pinned: x-universal-router-version: 2.1.2
Alternative: Omit x-universal-router-version to use the API default. The exact syntax for setting or removing a header depends on the client.
If the integration pins 2.0 and parses calldata
Review the parser and its validation rules rather than assuming an address-only update is enough. Uniswap says moving from 2.0 may require additional changes for integrators that parse calldata; it does not say every 2.0 integration needs the same code changes. [1]
If the application submits returned calldata without decoding it
Review the version-header setting and router-address allowlist. If a separate validator or decoder runs elsewhere in the transaction flow, include it in the migration review. Confirm that the address returned by the API is permitted for the relevant chain.
What should teams verify for Router 2.1.2?
Check the 2.1.2 deployment and address for every supported chain before changing production configuration. Do not reuse an address across networks without verifying it against Uniswap’s supported-chains documentation. [2]
- Check Ethereum mainnet. Uniswap lists chain ID 1 and the Universal Router 2.1.2 address 0x23617e59A5925b2A4Bf75d73ff6711cD0b29De85. [2]
- Check each other chain separately. Verify the deployment and address for every network the integration uses. [2]
- Confirm default behavior. When the version header is omitted, Uniswap says the API defaults to 2.1.2 on chains with a 2.1.2 deployment. [2]
- Recheck before deployment. Verify the supported-chain details against current documentation before relying on them in production. [2]
How should teams monitor and test the migration?
Inventory the version pins, allowlists and calldata-handling paths, then apply explicit pass/fail checks before the cutoff. Uniswap lists @uniswap/universal-router-sdk 5.12.0 as the minimum version for decoding 2.1.2. [2]
- Inventory configuration. Find every use of the version header and record whether it pins 2.0, 2.1.1 or another version. List each router-address allowlist and the chains it covers.
- Map parsing and validation. Locate every calldata decoder and validator, and record the SDK version each uses. Include downstream services that inspect or transform returned calldata.
- Run the readiness checks. Before marking the migration ready, confirm that no request configuration pins 2.0 or 2.1.1; the returned router address matches the allowlist for that chain; representative returned calldata decodes and passes the integration’s validation; and logs show no remaining legacy-version requests before the cutoff.
- Check decoder behavior. Uniswap warns that an older SDK version, or decoding without the version argument, can fail or produce incomplete results. Test the actual decoder path and treat incomplete parsing as an integration issue to investigate. [2]
- Monitor and assign ownership. Track API errors, failed or incomplete parsing, and any remaining legacy-version requests. Assign an owner and remediation status to each affected integration. Separate API request failures from transaction-handling issues and pool-level observations.
A migration passes only when all applicable readiness checks pass. If a check fails, keep the affected integration on the remediation list and do not treat it as ready for the cutoff. These are operational acceptance criteria, not a claim that Uniswap requires a particular monitoring product or error threshold.
Does the API support change mean Ethereum DeFi TVL or APY is changing?
No. The cited notice reports no measured change in pool-level TVL, trading volume or LP returns. [1] API version errors belong in reliability monitoring; TVL and APY require separate pool-level observations and supporting data.
If API errors rise after the cutoff, investigate headers, allowlists and parsing before drawing conclusions about liquidity. Keep migration alerts separate from performance reporting and base market conclusions on independent pool data.
Frequently asked questions
Does the notice specify the time zone or exact time on October 21, 2026?
No. It gives October 21, 2026 as the effective date but does not specify a time or time zone. [1]
Does the notice state which HTTP status code the API returns?
No. It says requests pinning 2.0 or 2.1.1 will cause an API error response, but does not name an HTTP status code. [1]
Where can integrators verify 2.1.2 addresses for other chains?
Check Uniswap’s Supported Chains & Tokens documentation and verify the deployment and address for each chain the integration supports. [2]