Polymarket API rate limits — Gamma, Data & CLOB

Polymarket の API レート制限は、ボット、ダッシュボード、分析ツールを設計する際に考慮すべきスロットリング規則です。本ガイドでは各公開サーフェス（Gamma、Data、CLOB、Market WebSocket）の公表された制限を示し、特に Gamma の /markets に関する重要事項（/markets の 300 req / 10 s 規則やカーソルベースのページネーション）を説明します。さらに、バッチ、キャッシュ、カーソルページネーション、指数バックオフなど、クライアントを負荷下で安定させる具体的な戦略を提示します。

主なポイント

• Gamma の /markets エンドポイント: 10 秒あたり 300 リクエスト。ページネーションには limit パラメータと after_cursor を使う（offset は使用しない）。
• 結合リスティング制限: /markets + /events の呼び出しは合わせて10秒あたり 900 リクエストの上限を共有。Gamma 全体では 10 秒あたり 4000 リクエスト。
• 専用の読み取りには CLOB と Data API を利用。CLOB は取引呼び出しに API key + HMAC を要求するが、読み取りは公開。
• WebSocket（wss://ws-subscriptions-clob.polymarket.com/ws/market）はリアルタイムデータを提供する。ライブの板更新にはポーリングではなく WS を優先。
• 緩和パターン: リクエスト合流、キャッシュ TTL、ジッター付き指数バックオフ、レート認識キューイング、ページネーションに配慮した取得。

なぜレート制限が重要か

レート制限は Polymarket の共有インフラを保護し、ノイジーなクライアントが他者の体験を損なうのを防ぎます。アービトラージボットや分析システムを開発する際、制限に達するとリクエストが即座に拒否され、時間に敏感なフローが壊れる可能性があります。事前にリクエストパターンを計画しておくと、予期せぬ障害を減らしシステムを堅牢にできます。

ドキュメント化された Polymarket のレート制限とエンドポイント

Gamma（主要なマーケットメタデータ）

• Base URL: https://gamma-api.polymarket.com
• 主な制限:
  • /markets: 最大 10 秒あたり 300 リクエスト。ページネーションには limit（最大 1000）と after_cursor を使う。API は offset を HTTP 422 で拒否する。
  • /markets と /events の結合リスティング制限: 10 秒あたり 900 リクエスト。
  • Gamma API 全体のサーフェス: 10 秒あたり 4000 リクエスト。

実務上の注意点:

• 常に前回の呼び出しで返された after_cursor を使う。offset によるキーセット模倣は試みないこと。
• ラウンドトリップを減らすために limit を調整する。完全なマーケット一覧が必要なら limit=1000 を検討する。

Data（ポジション、トレード、ホルダー）

• Base URL: https://data-api.polymarket.com
• 認証: 公開読み取りは不要。
• ドキュメントはこのサーフェスを説明するが、Data の各エンドポイントごとの具体的なレート数値は列挙していない。Data は公開だが、Gamma と同様に保守的なクライアント側制御（バッチ、キャッシュ、バックオフ）を実装することを推奨する。

CLOB（オーダーブックと取引）

• Base URL: https://clob.polymarket.com
• 読み取りは公開。取引は API key + HMAC が必要。
• CLOB サーフェスはオーダーブック、ミッドポイント、価格履歴、注文作成/キャンセルを公開する。CLOB 読み取りのエンドポイント別の明示的なレート数値は公表されていないため、取引経路はレートに敏感だと見なして、可能なら CLOB WebSocket や Market WS を使ってライブブックデータを取得すること。

Market WebSocket（リアルタイムの市場更新）

• URL: wss://ws-subscriptions-clob.polymarket.com/ws/market
• マーケットデータには認証不要。
• フィード: リアルタイムブック、price_change、best_bid_ask（custom_feature_enabled: true で有効化）、last_trade_price、tick_size_change。
• 10 秒ごとの PING ハートビート。接続ごとの最大楽器数は 500。

従うべき Gamma /markets の詳細

• ページネーション: after_cursor のみ。API は next_cursor を返す — 何も変えずに次の呼び出しに渡すこと。
• limit のデフォルトは 20、最大は 1000。バルク同期では大きめの limit を使う。
• 受け付けるフィルターパラメータには slug、id、condition_ids、clob_token_ids、question_ids、market_maker_address の配列や、closed、active、archived、tag_id などがある。
• ソート: order はカンマ区切りのフィールドリスト（例: volume24hr,liquidity）を受け取り、ascending はデフォルト true のブール値。

一般的なエラーシグナルと対処方法

• HTTP 429（レート制限）: 即時ポーリングを止め、バックオフしてジッター付き指数バックオフで再試行する。
• HTTP 422（offset 使用時）: after_cursor ページネーションに切り替える。
• 部分応答や空ページ: カーソルを尊重し、フィルターを検証する。サーバー側のクォータに達したと考えられる場合は、クライアントの同時実行数を減らす。

スロットリングを避けるための設計パターン

1. 積極的にキャッシュする

• マーケット一覧やメタデータは短めの TTL（30 秒〜2 分）でキャッシュする。マーケットやイベント一覧は毎秒変わることは稀。
• クエリーキー（フィルター + order）ごとにキャッシュを保持する。WS の変更イベントを受け取ったとき、または TTL 期限切れ時にのみ無効化する。

2. バッチ化と limit 増加

• フル同期では /markets に limit=1000 を指定してラウンドトリップを削減する。
• ピーク外の時間にワイドページを引いておき、差分は WebSocket で取り込む。

3. リアルタイムデータには WebSocket を使う

• ライブのオーダーブック更新や価格変動は、Gamma や CLOB のポーリングより Market WS 購読で取得するのが効率的。WS は接続ごとに最大 500 楽器をサポートする。500 を超える場合はクライアントをシャーディングする。

4. レート認識キューとバックオフ

• ドキュメントで示されたピーク（例: /markets の 300/10s）に合わせたリーキー・バケットやトークン・バケットのクライアント側リミッターを実装する。
• 429 を受け取ったらジッター付き指数バックオフを適用し、リトライ間隔を段階的に拡大する。

5. 同一の同時リクエストを合流させる

• アプリの複数箇所が同じ /markets クエリを同時に要求する場合、インフライトの単一リクエストにまとめてレスポンスを扇出する。

6. カーソル優先の同期

• 常にカーソルベースのページネーションに従う。ライブ同期では最初のページを取得して差分購読に切り替える。Gamma のエンドポイント制限を超えるような無分別な並列カーソル取得は避ける。

取得戦略の例

• バルクインデックス作成ジョブ（非リアルタイム）: /markets?limit=1000 を取得し next_cursor が尽きるまで辿る。ページ間は短時間スリープし、300/10s のエンドポイント制限を守る。
• 処理がほぼリアルタイムの UI: ベースセットを一度取得して（キャッシュ 30 秒）、その後 WebSocket で差分と best_bid_ask 更新を受ける。
• ウォッチリストのマイクロクライアント: >500 楽器なら複数の WS 接続にウォッチリストをシャードする。

ボットと高スループットクライアント向けの運用ガイダンス

• ブックレベルのデータには CLOB WebSocket または CLOB の読み取りを使い、Gamma は遅いメタデータ用に使う。
• 取引認証情報（CLOB API key + HMAC）は厳重に保護する。取引エンドポイントは認証が必要。
• 429 の発生率やエンドポイントごとのレイテンシを監視する。公表された上限に定期的に近づくなら、アクセスを申請するか公式の Polymarket チャネルに相談する（Builder Program は高ボリューム統合とアトリビューションのための道筋）。

開発とデプロイに与える影響

トレーディングボットや分析サービスを構築する場合、層別のデータフローを計画することが重要です。大きな limit での Gamma からの初回バルク取得、続いて WebSocket 購読でのライブ更新、そして WS フィードにないメタデータ用の小規模な定期的 Gamma ポーリング（キャッシュ付き）を組み合わせます。クライアント側のレート制限、合流、カーソル対応ページネーションを実装して、/markets の 10 秒あたり 300 リクエスト上限や結合リスティング、Gamma 全体の上限に達しないようにしてください。

まとめ

Polymarket の API レート制限は Gamma のリスティング系サーフェスに対して明確に定められており、Market WS はライブフィードのスケーラブルな代替手段を提供します。after_cursor によるカーソルベースのページネーションを中心に設計し、limit を戦略的に使い、高頻度データには WebSocket を優先してください。これらのパターンを守ることでスロットリングを減らし、統合の信頼性を向上させます。

Frequently asked questions

What is the /markets rate limit on Gamma?

Gamma の /markets エンドポイントは 10 秒あたり 300 リクエストに制限されています。limit（最大 1000）と after_cursor によるカーソルページネーションを利用してください。offset は使わないでください — API は HTTP 422 で拒否します。

Are there combined limits for Gamma endpoints?

はい。/markets と /events へのリスティング呼び出しは 10 秒あたり 900 リクエストの結合上限を共有します。加えて、Gamma API 全体のサーフェスは 10 秒あたり 4000 リクエストに制限されています。

Should I poll Gamma or use the WebSocket for live updates?

ライブの板や価格更新には Market WebSocket（wss://ws-subscriptions-clob.polymarket.com/ws/market）を優先してください — これは効率的で、繰り返しのポーリングを避けられます。Gamma は変化が遅いメタデータや初期のバルク同期用に使います。

What should my client do on HTTP 429 responses?

429 を受け取ったら攻撃的なポーリングを止めるシグナルとみなし、ジッター付き指数バックオフを実装し、同時実行数を減らし、同一リクエストを合流させてください。429 をトラッキングしてレートリミッターを動的に調整します。

Does the CLOB API require authentication?

CLOB の読み取りは公開です。CLOB 上の取引操作は API key と HMAC による認証が必要です。取引レート制限を尊重し、ブック更新には WS フィードを優先してください。