如何选择 Polymarket 数据 API

如果你正在找 Polymarket 历史数据，你一定已经撞上了把所有人引到这里的那堵墙：Polymarket 自己的 API 只提供当前状态。请求已结算市场的订单簿会得到 404；它保留的价格历史大约每分钟一个点，没有任何深度信息。这两点都与套餐无关。订单簿就是不存在。

所以你需要一家在市场运行期间就记录了订单簿的提供商。问题在于，这个领域的每家提供商都在宣传同一个头条数字，而它几乎是最没有信息量的那个。下面是你应该检查的东西。

1. 看每个市场每分钟的快照数，而不是快照总数

快照总数到处都是头条数字，但它几乎毫无意义。总数不过是采集频率 × 跟踪的市场数 × 采集时长。数字更大的提供商可能精度更高，也可能只是采集时间更长，或者在没人交易的市场上计入了冗余的行。

你真正需要知道的是：在我关心的那个具体市场上，我每分钟能拿到多少条快照？一个每分钟采样两次的 5 分钟市场，只给你十个数据点来为整个市场生命周期建模。这不足以测试任何东西。

# Pull the same market from each provider, then compare density.
snaps = fetch_snapshots(market_id)          # provider-specific call

span_s  = (snaps[-1]["timestamp"] - snaps[0]["timestamp"]) / 1000
per_min = len(snaps) / (span_s / 60)

print(f"{len(snaps)} snapshots over {span_s:.0f}s = {per_min:.1f}/min")

# Gaps matter more than the average. One 90-second hole in a 5-minute
# market means you cannot model the part where it was decided.
gaps = [
    (b["timestamp"] - a["timestamp"]) / 1000
    for a, b in zip(snaps, snaps[1:])
]
print(f"max gap: {max(gaps):.1f}s   median: {sorted(gaps)[len(gaps)//2]:.1f}s")

2. 是真实的订单簿深度，还是只有盘口最优价？

这是决定你的回测是否有意义的最大单一因素，也是营销话术最滑头的地方。“订单簿数据”可以指从完整的价格阶梯到单一的买价/卖价对之间的任何东西。

如果你打算以任何有意义的规模交易，你就需要价格阶梯。在一个流动性很薄的 Up/Down 市场里，一笔 500 份的订单不会在第一档成交，它会逐档吃单，而第一档价格与你真实平均成交价之间的差距，经常比你要测试的优势还大。

def simulate_fill(levels, qty):
    """Walk the ladder. This is what actually happens to your order."""
    filled = cost = 0.0
    for lvl in levels:
        take = min(lvl["size"], qty - filled)
        cost += take * lvl["price"]
        filled += take
        if filled >= qty:
            break
    if filled < qty:
        return None            # Not enough liquidity to fill at all.
    return cost / filled

book = snapshot["orderbook"]["asks"]
print("top of book:", book[0]["price"])
print("true fill  :", simulate_fill(book, 500))
# A gap of 2-3c here on a $1 binary is routine, and it is
# larger than most claimed edges.

3. 已结算的市场真的被保留了吗？

为这些数据付费的全部理由，就是 Polymarket 把它们丢弃了。所以要确认提供商确实保留了这些数据，而不是用缓存代理实时端点。

这个测试只需一分钟：找一个几周前结算的市场，请求它的快照，确认你拿到的是带深度的完整价格路径，而不只是一条说明哪一方获胜的元数据记录。知道结果不等于有数据；每个值得测试的策略关注的都是路径，而不是答案。

4. 历史窗口与历史深度

提供商以两种不同的形式出售历史数据，这个区别比天数本身更重要：

• 滚动窗口：最近 N 天，更早的数据会过期移除。适合针对当前市场条件进行调优。
• 保留的存档：自开始采集以来的全部数据。如果你想在不同波动率环境下测试，这是必需的。

你需要哪种，老实说取决于你的策略。如果你交易 5 分钟市场并每周重新调优，30 天就足够了，为更多数据付费是浪费。如果你想知道你的优势能否扛过去年的市场条件，滚动窗口无论多少钱都回答不了这个问题。

5. 你真正能用上的吞吐量

速率限制听起来像个细节，直到你运行第一次真正的回测。把三个币种一个月的 5 分钟市场的所有快照都拉下来需要大量请求，10 次请求/秒的限制会把一个下午的研究变成一个通宵的任务。

有两个数字很重要，而提供商往往只公布一个：持续吞吐量（每分钟请求数）和突发容量（每秒请求数）。每分钟限制很高但突发限制很低，并行拉取依然会卡住。

如果你经常拉取大量历史数据，还要问一下有没有批量导出的途径。通过 REST 端点分页拉取一百万条快照是可行的，但那不是合适的工具。

6. 付费前能评估吗？

你没法从营销页面上评估数据质量。任何对自己数据有信心的提供商，都会让你在付费之前先看看数据，通过免费档或试用，最好还有一份无需注册就能阅读的 API 参考。

不过要清楚免费档或试用的用途。我们的是完整 Builder 套餐的 3 天试用，包含订单簿深度，让你可以在决定之前检查覆盖范围、快照密度和响应结构；但三天时间加上 14 天的窗口，让它成为一个评估工具，而不是一个研究档位。无论是哪家提供商，在下结论之前，先弄清楚哪些部分是真正可以免费试用的。

7. 你的工具能读懂文档吗？

这是一个较新的考量，值得检查，因为在出问题之前你根本看不到它。如果你用 Cursor、Claude Code 或 Codex 进行开发，你的助手能否写出正确的集成代码，取决于它能否读到提供商的文档。

有些数据提供商在 robots.txt 中屏蔽了 AI 爬虫。这是关于训练数据的合理选择，但这意味着模型看不到他们的文档，只会自己编造一套 API 接口。你可以在大约五秒钟内检查任何提供商：

curl -s https://<provider>/robots.txt | grep -iA1 "GPTBot\|ClaudeBot\|Google-Extended"

# "Disallow: /" under those agents means your AI assistant
# cannot read their docs and will guess at the API instead.

作为参考，PolyTest 允许这些爬虫，并发布了 llms.txt、llms-full.txt 和一份 OpenAPI 规范。不过实际的测试比阅读策略文件更简单：让你的助手针对每家提供商写一个集成，看哪一家能产出可以运行的代码。

什么时候你不应该付钱给任何人

这一点值得直说，因为它对我们和对任何人一样适用。如果符合以下情况，你不需要付费的数据提供商：

• 你只需要实时数据。Polymarket 的公开 API 和 WebSocket 数据流是免费的，市场数据无需认证，而且完全够用。历史数据提供商只为历史数据而存在。
• 你在测试基础设施，而不是策略。认证、解析、重连和速率限制处理，都可以对着免费的实时端点进行检验。
• 你的策略不依赖成交。如果你研究的是基础概率或结算频率，这些信息在公开元数据中都还保留着。
• 你愿意自己记录。对着公开的 WebSocket 运行一个采集程序是完全可行的。代价是一台小服务器，以及让它持续运行的自律。问题在于你的历史数据从零开始，而且无法回补，所以只有在你远早于需要数据之前就开始采集，它才有用。

付费的理由既狭窄又具体：你想要的是你没有记录过的历史数据，并且从今天就要。

一个今天下午就能做的测试

1. 注册你名单上每家提供商的免费档或试用。
2. 选一个市场（同一币种、同一时间周期、同一天），从每家拉取数据。
3. 比较每分钟快照数和最大间隔。密度和连续性胜过任何头条数字。
4. 检查每条快照的订单簿档数。如果不是价格阶梯，你就无法为成交建模。
5. 请求一个一个月前结算的市场，确认你拿到的是完整路径，而不只是结果。
6. 运行你最重的实际查询模式，看哪家提供商最先限流。
7. 让你的 AI 助手针对每家写一个集成，看它实际能读懂哪家的文档。

这套流程只需一个下午，告诉你的比任何对比表都多，包括这一篇。如果你想从我们这里开始，有 3 天免费试用，端点参考也完全开放，无需注册即可阅读。