Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
---
title: 'Enforcement of Slippage Validation'
description: 'Posted: September 4, 2026 | Effective: October 4, 2026'
type: changelog
datePublished: '2026-09-04'
---

On October 4, 2026, we will begin enforcing that every `/quote` request include either `autoSlippage` or `slippageTolerance`.

**What is changing?**

The [API Reference](/docs/api-reference/aggregator_quote) already documents that every `/quote` request must include either a `slippageTolerance` or an `autoSlippage` field. That requirement has not been enforced. Starting October 4, 2026, requests that omit both fields will be rejected.

**Why is this changing?**

This change ensures that integrators or their end users explicitly choose a slippage setting, rather than relying on an implicit default that may not match their intent.

**What do I need to do?**

If your `/quote` requests do not currently set `slippageTolerance` or `autoSlippage`, you must start setting one of them, as described in the [`/quote` API Reference](/docs/api-reference/aggregator_quote). If you already set one of these fields on each request, no change is required.
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
title: 'Improved API Error Codes'
description: 'Posted: August 20, 2026 | Effective: September 4, 2026'
type: changelog
datePublished: '2026-08-20'
---

Additional HTTP 404 error codes that provide more informative error reasons are being added to the `/quote` endpoint of the API.

**What is changing?**

When a `/quote` request returns an HTTP 404, the response will include more specific `errorCode` values and a `detail` field.

| `errorCode` | Meaning | Retry? |
| --- | --- | --- |
| `QuoteAmountTooLowError` | Below the minimum quotable size for the requested protocol (e.g. UniswapX per-chain minimums) | No |
| `NoRouteFoundError` | Routing completed, but no viable route was found | No |
| `UnsupportedTokenError` | Token is not routable (e.g. unknown, blocklisted, or on the wrong chain) | No |
| `UnsupportedChainError` | Chain is not supported for the requested operation | No |
| `UniswapXNotSupportedOnChainError` | The requested UniswapX variant is not supported on this chain | No |
| `UpstreamTimeoutError` | A routing dependency timed out or errored; it is unknown whether a route exists | Yes |
| `ResourceNotFound` (fallback) | Unclassified failure | Yes (conditionally) |

For clarity, the HTTP 404 error structure is not changing and will continue to look like:

```json
{
"errorCode": "UnsupportedTokenError",
"detail": "Token not routable (unknown / blocklisted / wrong chain)",
"requestId": "a00382a5539523928a4f997974dd27eb"
}
```

**Why is this changing?**

Except for field-level validation errors, the `/quote` endpoint usually returned an `errorCode` of `ResourceNotFound` when it could not return a quote. This catch-all error was not specific enough for integrators to tell users whether to retry the request or change its parameters.

**What do I need to do?**

If you parse the `errorCode` field for specific actions or display, add handling for the new error codes. We also recommend a default case so your integration can tolerate additional error codes in the future.

If you pass through the `detail` field from an HTTP 404 response to your users or interface, no change is needed.
11 changes: 3 additions & 8 deletions content/changelog/active-notifications/meta.json
Original file line number Diff line number Diff line change
@@ -1,13 +1,8 @@
{
"title": "Active Notifications",
"pages": [
"uniswapx-live-on-robinhood-chain",
"sunset-of-blast-support",
"uniswapx-rfq-auctions-on-base-and-arbitrum",
"uniswapx-live-on-avalanche-base-bnb-and-tempo",
"recipient-parameter-on-trading-api",
"sunset-of-api-key-based-fees-and-fields",
"proxy-approval",
"setting-a-fee-through-the-api"
"sunset-of-universal-router-2-0-and-2-1-1",
"enforcement-of-slippage-validation",
"improved-api-error-codes"
]
}
24 changes: 0 additions & 24 deletions content/changelog/active-notifications/proxy-approval.mdx

This file was deleted.

This file was deleted.

This file was deleted.

This file was deleted.

Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
---
title: 'Sunset of Universal Router 2.0 and 2.1.1'
description: 'Posted: September 21, 2026 | Effective: October 21, 2026'
type: changelog
datePublished: '2026-09-21'
---

We are introducing Universal Router 2.1.2 as of September 21, 2026, and sunsetting support for Universal Router 2.0 and 2.1.1 on October 21, 2026.

**What is changing?**

Universal Router 2.1.2 is deployed across the chains listed on [Supported Chains](/docs/trading/swapping-api/supported-chains), and the API already routes to it by default. Universal Router 2.1.2 is the new recommended version for all API integrators. Starting October 21, 2026, requests that pin 2.0 or 2.1.1 through the `x-universal-router-version` header will cause an error response from the API.

**Why is this changing?**

The new version of Universal Router carries important improvements and fixes, including all of the changes in Universal Router 2.1.1. To reduce operational complexity and to simplify the integration experience, we are sunsetting the older versions of Universal Router.

**What do I need to do?**

If you pin a router version with the `x-universal-router-version` header, set it to `2.1.2` or drop the header to take the API default. If you allowlist router addresses in a wallet or in a contract, add the 2.1.2 address for every chain you use.

Moving from 2.1.1 to 2.1.2 does not require any change aside from accepting the new Universal Router 2.1.2 address. There are no calldata or ABI changes, so a 2.1.1 integration can repoint to the 2.1.2 addresses without requiring any SDK, parsing, or other changes in calldata processing.

Moving from 2.0 to 2.1.2 does require changes beyond accepting the new Universal Router address, if you parse the calldata. New arguments and commands meaningfully change the calldata and may require that you update the SDK you use if you parse the calldata. See [SDK compatibility for decoding calldata](/docs/trading/swapping-api/supported-chains#sdk-compatibility-for-decoding-calldata) for the SDK release and `UniversalRouterVersion` to use.

If you do not set the `x-universal-router-version` header, you will automatically receive Universal Router 2.1.2.

This file was deleted.

This file was deleted.

Loading
Loading