このページは機械翻訳されています。英語の原文が正式版です。 英語で読む →
メインコンテンツにスキップ

レート制限

注文操作と API リクエストに対するウォレット単位のレート制限です。

概要​

レート制限は 60 秒の固定ウィンドウで行われます。ウォレットの制限はそのウォレットのティアによって決まり、以下に適用されます。

  • 注文の発注 (POST /order、PUT /order、WebSocket PlaceOrder、およびTEEルートのパーペチュアル注文の送信)
  • 注文のキャンセル (DELETE /order、DELETE /order_cloid、およびTEEルートのパーペチュアルのキャンセル)
  • API リクエスト (ウォレット単位の読み取りおよびその他の署名付き書き込み)

キャンセル、エージェント認可、MMP の書き込み、公開リスクシミュレーションには、ネットワークソースをキーとする別個の制限と、プロセス全体の上限が適用されます。

カウンターは各 API プロセスのメモリ上で保持されます。レプリカ間では共有されないため、公表している数値はクラスター全体の予算ではなく、単一のプロセスが受け付ける上限として扱ってください。

デフォルトの制限​

ティア注文/分キャンセル/分API リクエスト/分最大オープン注文数最大ポジション数
デフォルト6012060010050
Tier 130603005020
Tier 21203001,200500200
マーケットメイカー1,2002,4006,0005,000無制限

新しいウォレットにはデフォルトの制限が適用されます。ティアのアップグレードについてはサポートにお問い合わせください。現在の API リクエスト制限は、ウォレット単位の読み取り (例: GET /orders?wallet=...) のレスポンスに含まれる X-RateLimit-Limit ヘッダーで確認できます。

レート制限のレスポンス​

レート制限を超えると、API は 429 Too Many Requests を返します。

{
  "error": "rate_limit_exceeded",
  "message": "Rate limit exceeded for OrderPlacement: 60 per minute, retry after 45 seconds",
  "retry_after_secs": 45,
  "limit": 60
}

レスポンスヘッダー​

ウォレット単位で制限されるエンドポイントは、以下のヘッダーを返します。429 には X-RateLimit-Limit、X-RateLimit-Remaining: 0、Retry-After が含まれますが、X-RateLimit-Reset は含まれません。

ヘッダー説明例
X-RateLimit-Limitウィンドウあたりの最大リクエスト数60
X-RateLimit-Remaining現在のウィンドウで残っているリクエスト数42
X-RateLimit-Resetウィンドウがリセットされる Unix タイムスタンプ (秒、成功レスポンスのみ)1737312060
Retry-Afterリトライまでの秒数 (429 のみ)45

レスポンスヘッダーの例​

成功したリクエスト:

HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 42
X-RateLimit-Reset: 1737312060

レート制限されたリクエスト:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0

レート制限のカテゴリー​

レート制限はアクションの種類ごとに個別に追跡されます。

注文の発注​

ウォレットごとに、ティアの「注文/分」に対してカウントされます。

  • POST /order および PUT /order
  • WebSocket PlaceOrder
  • POST /v1/tee-perp/orders/submit およびその他のパーペチュアル注文の送信 (Account のマネージャーに対してカウント)

POST /bulk_order と PUT /bulk_order は、1 リクエストあたり 50 件までに制限されます。

注文のキャンセル​

ウォレットごとに、ティアの「キャンセル/分」に対してカウントされます。

  • DELETE /order および DELETE /order_cloid
  • パーペチュアルのキャンセル (署名した API ウォレットに対してカウント)

DELETE /bulk_order と DELETE /bulk_order_cloid を含むすべてのキャンセルルートは、署名検証の前にも、1 分あたりネットワークソースごとに 6,000 レッグ、プロセス全体で 60,000 レッグに制限されます。一括キャンセルでは、1 エントリーにつき 1 レッグとしてカウントされます。

API リクエスト​

ウォレットごとに、ティアの「API リクエスト/分」に対してカウントされます。

  • ウォレット単位の読み取り (wallet クエリパラメーターをキーとする)
  • 上記以外の署名付き書き込み (MMP の設定や証拠金モードなど)

RFQ の送信​

POST /rfq/request と WebSocket の RFQ 送信コマンドは、ティアに関係なく、ウォレットごとに 1 分あたり 10 件に制限されます。

リスクシミュレーション​

公開のポートフォリオおよび注文のシミュレーション (POST /risk/simulate/portfolio、 POST /risk/simulate/orders、およびパーペチュアルのプレビュー POST /v1/tee-perp/preview) には、1 分あたりネットワークソースごとに 60 リクエスト、プロセス全体で 600 リクエストという 別個の制限があります。1 つの API プロセスで同時に実行されるシミュレーションは最大 4 件です。 クォータを超えたリクエスト、またはシミュレーションワーカーが飽和している場合のリクエストには、429 Too Many Requests が返されます。

エージェント認可​

POST /approve-agent、DELETE /revoke-agent、DELETE /revoke-all-agents は、署名検証の前に、1 分あたりネットワークソースごとに 120 リクエスト、プロセス全体で 1,200 リクエストに制限されます。

MMP の書き込み​

MMP の設定の書き込みは、ウォレットの API リクエスト制限に加えて、署名検証の前に、1 分あたりネットワークソースごとに 120 リクエスト、プロセス全体で 1,200 リクエストに制限されます。

ポジションと注文の制限​

レート制限に加えて、ウォレットには最大オープン注文数と最大ポジション数の制限があります。

制限の種類説明拒否
最大オープン注文数同時に保有できるオープン注文の最大数ウォレットが上限に達している間、新規注文は拒否されます
最大ポジション数ユニークなポジションの最大数 (-1 = 無制限)新しいポジションを建てることになる注文は拒否されます

これらは HTTP エラーではなく、注文の拒否です。注文レスポンスは HTTP 200 で、status: "REJECTED" と、次のような reason が返されます。

max_open_orders_exceeded: current=100, limit=100
max_positions_exceeded: wallet 0x... has 50 positions, limit is 50

ベストプラクティス​

レート制限への対処​

  1. ヘッダーを監視する: X-RateLimit-Remaining を事前に追跡してください
  2. Retry-After を守る: 指定された時間だけ待ってからリトライしてください
  3. バックオフを実装する: 429 が繰り返される場合は指数バックオフを使用してください
import time

def place_order_with_retry(order, max_retries=3):
    for attempt in range(max_retries):
        response = api.place_order(order)

        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            time.sleep(retry_after)
            continue

        return response

    raise RateLimitError("Max retries exceeded")

リクエストの使用量を最適化する​

  1. 一括エンドポイントを使う: 複数の注文は POST /bulk_order で 1 リクエストにまとめてください
  2. キャンセルをまとめる: 複数の DELETE /order リクエストの代わりに DELETE /bulk_order または DELETE /bulk_order_cloid を使用してください
  3. 更新には WebSocket を使う: GET /orders をポーリングする代わりに、注文の更新を購読してください

モニタリング​

クライアント側で以下のメトリクスを追跡してください。

  • アクションの種類ごとのリクエストレート
  • X-RateLimit-Remaining の推移
  • 429 レスポンスの頻度
  • Retry-After の平均時間

エラーリファレンス​

HTTP ステータスエラーコード説明
429rate_limit_exceededレート制限を超えました。指定された時間が経過してからリトライしてください

エラーの完全なリファレンスについては エラー を参照してください。

最終更新: