Correct UniswapX filler orders API rate limit to 4 RPS

[claude]

Requested by Angela Ocando · Slack thread

Summary

The UniswapX filler pages still publish a 6 RPS polling limit for the orders API. The deployed limit was lowered on 2026-09-02 and the published figure is now 4 RPS, so a filler following these pages polls above the limit and gets 429s.

• Filler FAQ: four occurrences of "rate limit at 6 RPS" (two in the FAQ frontmatter, two in the page body) are now 4 RPS. The "How do I get orders?" answer also picks up the fuller published wording: the endpoint serves cached responses, requests above 4 RPS return 429, and each response returns at most the last 50 orders, ordered by most recent.
• Filler overview: the filler role table said a non-exclusive filler "Polls the orders API at 6 RPS", now "at up to 4 RPS".
• Filler FAQ, one new entry ported from the published FAQ, which this mirror was missing: "Do I need an API key to poll for orders?" No, the orders API is a separate service from the Trading API and polling needs no API key, and the limit is keyed on the client IP rather than on a key, so raising a Trading API key's rate limit does not increase polling throughput.

Before and after, "How do I get orders?":

Before: Fillers should start with polling for orders and rate limit at 6 RPS.

After: Fillers should start with polling for orders and rate limit at 4 RPS. The orders endpoint serves cached responses, and requests above 4 RPS return 429. Each response returns at most the last 50 orders, ordered by most recent.

Two things deliberately left alone:

• content/trading/swapping-api/common-errors.mdx and faqs.mdx, which document a default of 6 requests per second per API key. That is the Trading API's per-key limit, a different service from the orders endpoint, and it matches what the developer portal publishes today. The new FAQ entry above exists to keep the two from being read as the same limit.
• archive/docs/contracts/uniswapx/fillers/filleroverview.md, which says "6rps". CONTRIBUTING.md states that archive/ holds the previous version of the repository for reference only and that PRs against it are not accepted, so the frozen copy stays as it is.

Type of change

• Fix (typo, broken link, incorrect or outdated content)
• New content (guide, page, code example)
• Update to existing content
• Other

How has this been verified?

• Checked the deployed configuration for the orders endpoint: the limit is 1200 requests per 5 minute window, which is 4.0 requests per second sustained, keyed on the client IP, returning HTTP 429 with body {"errorCode": "TOO_MANY_REQUESTS"} above it.
• Cross-checked against the currently published filler FAQ on developers.uniswap.org, which has said 4 RPS since 2026-09-03. The wording in this PR is taken from that page so the two stay in sync.
• Confirmed the trading pages' per-key 6 RPS figure is a separate, still-current limit before leaving it unchanged.
• Frontmatter of the edited faq.mdx parses, and no em-dashes were introduced.

Applicable screenshots

N/A, prose only.

Anything else reviewers should know?

The 6 RPS figure was correct for the orders endpoint until 2026-09-02, so anything else sourced from before that date is worth a second look. The stale figure also caused real confusion: a filler read a per-API-key limit elsewhere in these docs and concluded that using a different key would raise its polling throughput, which the new FAQ entry now rules out explicitly.

🤖 Generated with Claude Code

https://claude.ai/code/session_013WuaPUrQTFBfsT9rk7FXpa

---

Generated by Claude Code

[github-actions]

Thanks for contributing to Uniswap Docs! 🦄

Quick heads up on how this repo works: the docs you see on developers.uniswap.org are built from a separate source repo. When we accept a change here, we port it over there, so your fix might show up on the live site before it lands in this repo.

Updates to this repo come in batches on a regular cadence. When yours is included, you'll be credited as a co-author on the commit, so the contribution counts on your GitHub profile and in Uniswap/docs.

We review every PR but can't merge everything. Either way, someone from the docs team will follow up here once we've taken a look.

One legal bit: by submitting a PR you agree your contribution is licensed under the repo's MIT license.