リファレンス
本文レート制限
送れるリクエストの量、超えたときの挙動、そのほか知っておきたい制限。
制限は、サービスを共有するすべての人を守るためのものです。既定値は通常の利用には十分な余裕があり、制限にかかったときはレスポンスがどれだけ待てばよいかを正確に教えてくれます。
一覧
| 制限 | 既定値 | かかったとき |
|---|---|---|
アカウントあたりの書き込み（createTask、retry、アップロード …） | 10 秒あたり 1,000 回 | Retry-After 付きの 429 |
アカウントあたりの読み取り（recordInfo、models、jobs、quote …） | 10 秒あたり 1,000 回 | Retry-After 付きの 429 |
| アップロードのチケット | 10 秒あたり 1,000 回（書き込みとは別枠で追加） | Retry-After 付きの 429 |
利用レポート（/api/v1/usage） | アカウントあたり 1 分 30 回 | Retry-After 付きの 429 |
| アセットライブラリ | 1 分あたり読み取り 60 回・保存 30 回、加えて 1 日の新規作成数 | Retry-After 付きの 429 |
| キーの確認前のすべてのリクエスト | ネットワークあたり 1 分 6,000 回 | 429 |
| リクエスト本文 | JSON で 2 MiB まで | 413 |
| 残高 | アカウントにある分 | 40201 |
| キーの利用上限 | 設定しない限りなし | 40202 |
制限はアカウント単位で、キー単位ではありません。キーを増やしても上限は上がりません。
レスポンスヘッダー
| ヘッダー | 意味 |
|---|---|
X-RateLimit-Limit | 現在の時間枠の上限 |
X-RateLimit-Remaining | 枠内の残り回数。成功したレスポンスにも付くので、早めにペースを落とせます |
Retry-After | 429 のとき、再試行まで待つ秒数 |
上の数値は既定値で、変わることがあります。コードに埋め込まず、ヘッダーを信頼してください。
制限にかかったときの応答
{ "code": 429, "msg": "Too many requests. Retry in a moment", "request_id": "req_…" }上限を超えたリクエストはキューに入らず、すぐに拒否され、費用はかかりません。
対処法
- 少なくとも
Retry-After秒待ってから再試行します。複数のクライアントが一斉に戻らないよう、少しランダムな揺らぎを加えてください。 createTaskを再試行するときは同じIdempotency-Keyを送ります（冪等性）。- ポーリングは控えめに。画像は数秒ごと、動画は 10〜15 秒ごとです。さらに良いのは Webhook で、リクエストを一切消費しません。
多数のタスクを同時に動かす
レート制限が抑えるのはリクエストを送る速さで、同時に動くタスクの数ではありません。多くのタスクを並行して動かせ、長い動画は単に時間がかかるだけです。数千件のタスクを始めるなら、送信を分散させ、結果は Webhook で受け取りましょう。
キャンペーンの開始や大量処理で上限を上げたいときは、見込みの量を添えてお問い合わせください。