Polymarket API 速率限制：完整参考

如果你曾试图回答一个简单的问题，我每秒可以向 Polymarket 发送多少个请求？，你就会发现这个问题没有简单的答案。限制分散在两套独立的系统中，发布在不同的页面上，而且是以 10 秒窗口表示的，而不是大多数 API 使用的每秒或每分钟数字。

如果要查某个具体路由的限制，每个端点在 Polymarket API 参考中也都有自己的页面。

本页把所有有文档记录的限制集中在一处，解释这两套系统，并展示越过限制时实际会发生什么。所有数字都来自 Polymarket 官方文档，截至 2026 年 9 月有效。

两套不同的速率限制系统

这是让大多数开发者栽跟头的部分。Polymarket 运行着两个相互独立的限流器，在其中一个之下并不能保护你不被另一个限制。

Gamma API 速率限制

Base URL 为 https://gamma-api.polymarket.com。Gamma 提供市场和事件元数据，是大多数人探索平台时最先访问的端点。

Data API 速率限制

Base URL 为 https://data-api.polymarket.com。持仓、成交历史和投资组合数据。注意这个 API 比 Gamma 或 CLOB 严格得多：通用限制是每 10 秒 1,000 次，只有 Gamma 的四分之一。

Data API v2

Data API v2 于 2026 年 9 月 4 日在 https://data-api.polymarket.com/v2 上线，有自己的限制。v1 仍在提供服务，但已冻结：新的端点和字段只会出现在 v2 上。

CLOB API 速率限制

Base URL 为 https://clob.polymarket.com。订单簿本身。CLOB 的通用额度是所有 Polymarket API 中最高的（每 10 秒 9,000 次），但它分为四个限制差异很大的组。

通用

市场数据

这里要注意的规律是：单数端点为每 10 秒 1,500 次，复数批量端点为每 10 秒 500 次。在你想起一次批量调用就能覆盖许多代币之前，这看起来像是降级。批量请求每次的成本是单数的 3 倍，但每次调用完成的工作要多得多：永远优先用 /books，而不是循环调用 /book。

账本

认证

交易：突发与持续

交易端点是唯一有两个 Cloudflare 限制的端点：一个针对短时尖峰的突发限制，以及一个按 10 分钟计算的持续限制。你必须同时保持在两者之下。

每 10 秒 250 次的 DELETE /cancel-all 值得特别指出。每个重新报价周期都调用 cancel-all 的做市商会很快耗尽这个额度，而每 10 分钟 6,000 次的持续限制，平均下来每秒只有 10 次 cancel-all 调用。

Bridge、Relayer 及其他

按签名者令牌桶（CLOB 交易）

在 Cloudflare 之外，Polymarket 还会用按签名者令牌桶评估 CLOB 的下单和撤单请求。每个签名者地址有一个下单桶和一个撤单桶；消耗其中一个不会影响另一个。与 Cloudflare 层不同，超出这些限制会返回真正的 429。

请求消耗的是令牌，而不是每个请求计为一个单位：

交易量档位

你的桶大小取决于 maker 钱包在滚动 30 天窗口内的累计交易量。档位分配每三小时刷新一次。

用 burst_seconds = burst / rate_per_sec 计算一次完整突发能持续多久。对于 Standard 签名者是 60 / 40，即 1.5 秒的全速下单，之后就会被限制在每秒 40 个的补充速率。

读取速率限制响应头

按签名者限流器会在每个被评估的请求上返回响应头。这是监控额度最省成本的方式，不需要额外的 API 调用。

正确处理 429

正确的重试策略取决于你撞上的是哪个限流器，弄错了只会让情况更糟。有 Retry-After 时遵守它；没有时回退到带随机抖动的指数退避。随机抖动很重要：没有它，你的每个 worker 都会在同一时刻重试，立刻再次触发限制。

const MAX_RETRIES = 5;

async function polyFetch(url: string, init?: RequestInit): Promise<Response> {
  for (let attempt = 0; attempt <= MAX_RETRIES; attempt++) {
    const res = await fetch(url, init);

    // Watch the budget even on success — this is your early warning.
    const remaining = res.headers.get("Poly-RateLimit-Remaining");
    if (remaining !== null && Number(remaining) < 10) {
      console.warn(`Low token budget: ${remaining} (tier ${res.headers.get("Poly-RateLimit-Tier")})`);
    }

    // Warning mode: not rejected yet, but it would have been.
    if (res.headers.get("Poly-RateLimit-Warning") === "true") {
      console.warn("Request would be rejected under live enforcement — slow down.");
    }

    if (res.status !== 429) return res;
    if (attempt === MAX_RETRIES) return res;

    // Prefer the server's own answer, else exponential backoff.
    const retryAfter = res.headers.get("Retry-After");
    const baseMs = retryAfter
      ? Number(retryAfter) * 1000
      : Math.min(2 ** attempt * 250, 8000);

    // Full jitter — spreads a fleet of workers out instead of resynchronising them.
    await new Promise((r) => setTimeout(r, Math.random() * baseMs));
  }

  throw new Error("unreachable");
}

从设计上保持在限制之下

• 用批量代替循环。一次 /books 调用代替五十次 /book 调用，在每 10 秒 500 次的额度中只消耗一次请求，而不是在每 10 秒 1,500 次的额度中消耗五十次，余量提升 17 倍。
• 缓存元数据。/markets 返回的市场元数据在一个市场的生命周期内几乎不变，但 /markets 是 Gamma 中最严格的限制，每 10 秒 300 次。获取一次，缓存起来，别再在热循环中反复请求。
• 用 WebSocket 获取实时状态。用定时器轮询 /book 是耗尽请求额度最常见的方式。改为订阅数据流，让服务器推送变化。
• 给定时任务加入随机抖动。如果每个 worker 都在整分钟准时唤醒，你就会制造一个远高于平均速率的同步尖峰。随机化启动偏移。
• 关注延迟，而不只是错误率。由于 Cloudflare 是限流而不是拒绝，p99 延迟上升是你超出 IP 限制的第一个信号，远早于任何东西以错误的形式出现。
• 跟踪响应头。读取 Poly-RateLimit-Remaining 不花任何成本，它能准确告诉你还剩多少额度。

速率限制不等于数据访问

最后一点值得明确说明，因为这是我们见到的最常见的误解：没有任何速率限制档位能给你历史订单簿深度。Polymarket 的 API 提供的是订单簿的当前状态。它不提供上周二 14:03:17 订单簿是什么样子的历史存档，而市场一旦结算，它的订单簿就返回 404。

这是一个结构性缺口，而不是限流问题，再多的退避逻辑也解决不了。如果你想回测一个策略，你需要有人当时记录下来的时点快照，而这正是 PolyTest 存在的意义：240M+ 条 Polymarket 加密货币 Up/Down 市场的历史快照，带完整订单簿深度、亚秒级精度，没有缺口。