Polymarket 有 API 吗？架构、访问与集成指南

直接回答与范围

Polymarket 确实有 API。事实上，它根据你需要执行的操作暴露了多个 API 接口。公共 API（通常称为 Gamma API）无需认证即可提供市场元数据、事件列表和价格信息。需认证的 API（CLOB API）处理订单下达、取消和投资组合查询，需要钱包签名或 API 凭证。另外，由于 Polymarket 在 Polygon 上结算，所有交易和头寸也在链上可见，可以通过通用 RPC 提供商或索引服务进行查询。

本指南侧重于技术架构和集成工作流程。它不推荐 Polymarket 自身端点的特定提供商，但解释了如何为链上组件选择 RPC 基础设施。如需具体的端点和提供商建议，请使用 RPC Assistant。

• 公共 API：市场发现、订单簿、价格和搜索。
• 需认证 API：交易、订单管理和账户数据。
• 链上数据：Polygon 上的交易、头寸和结算。
• 访问可能受司法管辖区限制；请查阅您所在地区的官方文档。

假设与前提条件

在集成之前，你需要清楚了解自己的用例。你是在构建只读仪表板、交易机器人还是分析管道？每种都需要不同的 API 层级和基础设施组合。如果你计划直接与智能合约交互或验证链上状态，你还需要一个 Polygon RPC 端点。对于生产工作负载，建议使用专用节点或可靠的 RPC 提供商；共享公共端点有速率限制，不适合交易。

你还应熟悉 HTTP API、JSON 和基本加密签名（Polymarket 国际交易所使用 EIP-712）。对于美国监管的交易所，访问需要申请和 KYC 流程，因此请为入职预留时间。

• 一个 Polygon RPC URL（例如来自提供商或你自己的节点）。
• 一个兼容以太坊的钱包，带有用于签名的私钥（切勿硬编码）。
• 如果使用需认证的 CLOB API，则需要 API 凭证。
• 一个带有 curl 或你选择的编程语言的开发环境。

心智模型：Polymarket 数据的三个层级

将 Polymarket 的数据视为三个同心层。最外层是公共市场数据 API，针对发现和展示进行了优化。它回答诸如“存在哪些市场？”和“当前价格是多少？”等问题，无需身份验证。中间层是交易 API，需要认证且是有状态的：它管理订单、头寸和余额。最内层是区块链本身，每笔交易和结算都记录为链上事件。这一层不可篡改且可审计，但需要 RPC 连接才能查询。

稳健的集成通常会组合各层。例如，交易机器人可能使用公共 API 进行市场发现，使用需认证 API 下达订单，并使用直接 RPC 调用来验证结算或监控钱包活动。理解哪一层负责哪些职责可以防止冗余调用并提高可靠性。

公共 API：市场发现与定价

公共 API 是最简单的入口点。它通常暴露用于列出市场、检索订单簿和获取价格历史的端点。无需 API 密钥，但适用速率限制。确切的基 URL 和端点路径取决于你使用的是国际版还是美国版；请始终参考官方文档以获取正确的主机。以下示例使用占位基 URL 来说明请求模式。

curl -s "https://PUBLIC_API_BASE/markets?limit=5" | jq '.data[] | {question, slug, volume}'

需认证 API：交易与投资组合管理

交易需要认证。Polymarket 的国际交易所使用两级方案：第 1 级认证使用钱包的 EIP-712 签名来证明所有权，第 2 级使用 API 凭证（密钥、秘密、口令）通过 HMAC 对每个请求进行签名。美国交易所使用不同的模型，在 KYC 后获得 API 密钥。无论哪种情况，你都必须永远不要在客户端代码中暴露私钥或 API 秘密。

以下 Python 代码片段演示了如何使用 requests 库和 eth_account 进行签名来构建签名请求。它仅用于说明，为简洁起见省略了错误处理。

import requests, time, hmac, hashlib, base64
from eth_account import Account
from eth_account.messages import encode_typed_data

# Placeholders: replace with your own values
PRIVATE_KEY = "YOUR_PRIVATE_KEY"
API_KEY = "YOUR_API_KEY"
API_SECRET = "YOUR_API_SECRET"
API_PASSPHRASE = "YOUR_PASSPHRASE"
BASE_URL = "https://AUTHENTICATED_API_BASE"

account = Account.from_key(PRIVATE_KEY)

# Example: sign a message to obtain L2 credentials (simplified)
# In practice, follow the official authentication flow.

def sign_request(method, path, body=""):
    timestamp = str(int(time.time() * 1000))
    message = timestamp + method + path + body
    signature = hmac.new(
        base64.b64decode(API_SECRET),
        message.encode(),
        hashlib.sha256
    ).digest()
    return base64.b64encode(signature).decode()

headers = {
    "POLY_API_KEY": API_KEY,
    "POLY_PASSPHRASE": API_PASSPHRASE,
    "POLY_TIMESTAMP": str(int(time.time() * 1000)),
    "POLY_SIGNATURE": sign_request("GET", "/orders"),
}

resp = requests.get(f"{BASE_URL}/orders", headers=headers)
print(resp.json())

链上数据与 RPC 基础设施

由于 Polymarket 运行在 Polygon 上，每笔交易和结算都是链上事件。你可以使用 Polygon RPC 端点直接查询这些事件。这对于构建分析、验证成交或监控钱包活动而无需依赖交易 API 非常有用。然而，公共 RPC 端点通常有速率限制，可能无法提供你所需的历史数据。对于生产系统，请使用提供归档数据和高吞吐量的专用节点或托管 RPC 服务。

选择 RPC 提供商时，请考虑请求延迟、速率限制、归档支持和可靠性。OnFinality 为 Polygon 和其他网络提供托管 RPC 端点；你可以在定价页面上比较套餐。有关 RPC 架构的更深入讨论，请参阅 RPC 端点指南。

• 使用 eth_getLogs 查询 Polymarket 合约事件。
• 按合约地址和主题过滤以减少数据量。
• 对于历史查询，确保你的提供商支持归档数据。
• 考虑使用 WebSocket 订阅获取实时交易流。

curl -s -X POST "YOUR_POLYGON_RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [{
      "address": "0xCONTRACT_ADDRESS",
      "fromBlock": "0x0",
      "toBlock": "latest",
      "topics": ["0xEVENT_TOPIC"]
    }],
    "id": 1
  }'

验证流程：测试你的集成

设置 API 调用后，请独立验证每一层。从公共 API 开始：获取市场列表并确认响应包含预期字段。然后通过调用只读的需认证端点（如 /orders）并检查是否返回 200 状态来测试认证。最后，通过获取最新区块号和已知事件日志来测试链上查询。记录每次调用的延迟和成功率。

下表概述了一个简单的验证矩阵。在您自己的环境中运行每个测试三次并记录结果。不要依赖虚构的基准；用你的实际基础设施进行测量。

• 公共 API：GET /markets 返回 200 和有效的 JSON。
• 需认证 API：带有有效标头的 GET /orders 返回 200。
• RPC：eth_blockNumber 返回最近的区块高度。
• RPC：对已知合约的 eth_getLogs 返回预期事件。

常见陷阱与故障排除

开发者经常遇到文档不匹配的问题，尤其是美国 API。例如，查询参数可能需要 snake_case 而不是 camelCase，活跃市场过滤器可能返回过时事件。始终根据官方模式验证响应，并准备好调整字段名称。地理封锁是另一个常见问题：国际 API 可能无法从某些司法管辖区访问，而美国 API 需要 KYC。如果你收到 403 或 451 状态，请检查你的地区和账户状态。

速率限制是另一个挑战。公共 API 的限制比需认证 API 更严格。实现指数退避并尽可能缓存响应。对于链上查询，批量处理 eth_getLogs 请求并使用具有宽松限制的提供商。如果你遇到 API 与链上状态之间的数据不一致，请记住 API 可能是最终一致的；区块链是真相来源。

• 检查参数大小写（snake_case 与 camelCase）。
• 验证你的 IP 未被地理封锁。
• 通过重试和退避处理 429 响应。
• 使用区块链来调和差异。

局限性与权衡

Polymarket 的 API 功能强大，但不是通用数据仓库。公共 API 是为市场发现而设计的，不是用于批量历史分析。如果你需要跨市场聚合或长期回填，你可能需要自己索引链上数据或使用第三方索引服务。需认证 API 是有状态的，并且可能停机；构建回退和幂等订单处理。

链上查询提供最可靠的历史记录，但需要更多基础设施。你必须管理 RPC 连接、处理重组并高效存储数据。对于高频交易，到 RPC 端点的延迟很重要；将你的基础设施与提供商共置可以帮助解决。最终，正确的架构取决于你的用例：仪表板可以依赖公共 API，而交易机器人需要需认证 API 和专用 RPC 的组合。

后续步骤：构建弹性集成

首先使用公共 API 进行原型设计以了解数据模型。然后，从 OnFinality 等提供商处设置 Polygon RPC 端点并测试链上查询。一旦你熟悉了，申请 API 凭证并实现认证流程。始终分离你的读和写路径，并监控两者的错误和延迟。

对于生产部署，考虑使用专用节点以避免速率限制并确保一致的性能。你可以探索 OnFinality 的专用节点产品并比较 RPC 定价。如果你需要帮助为 Polygon 选择 RPC 提供商，RPC Assistant 可以根据你的需求提供简短建议。

• 使用公共 API 和测试网 RPC 进行原型设计。
• 实现认证和安全密钥存储。
• 为 API 和 RPC 调用设置监控。
• 随着交易量增长，使用专用基础设施进行扩展。