共通仕様 / レート制限

API のエンドポイントには、受け付けられるリクエスト数の上限があります。

プロダクトごとの上限値

エンドポイントごとの値は各プロダクトのドキュメントを参照してください。

プロダクト	上限値
SMS/RCS	エンドポイントごとの上限

レート制限に関する原則

開発者向けドキュメントに記載されたレート制限は、特に明記しない限り、原則として「これ以上受け付けられない」という単位時間あたりに処理できる API リクエスト数の上限を示しています。パフォーマンスはベストエフォートの提供であり、上限と同等のパフォーマンスが常に提供されることを保証するものではありません。状況によって実際の単位時間あたりに処理可能な API リクエストは記載されたレート制限を下回る場合があります。

レート制限の上限を緩和する場合は変更の 2 週間前に、厳格化する場合は変更の 3 ヶ月前に、担当の営業よりご連絡いたします。

特定の値に依存せず、上限に達した場合の処理を必ず実装してください。

上限が適用される範囲

配信系の API は、配信リクエストを受け付けるところまでを担当します。受け付けたリクエストは非同期に処理され、実際のメッセージ送出はそのあとに行われます。

レート制限が適用されるのは、図の実線の部分＝受け付けまでです。受け付けの上限までリクエストを送れたとしても、それと同じ速度でメッセージが送出されるわけではありません。

実際のメッセージ送出の進捗は、配信系 API のレート制限とは独立して管理されます。進捗の確認に使う API はプロダクトごとに異なります。

レート制限の境界

レート制限の上限は認証に使用するクライアント ID × エンドポイント単位で数えます。

• 同じクライアント ID を使った API リクエストは、どのサーバーから送っても合算されます
• 別のエンドポイントへのリクエストは、互いの上限を消費しません。ある配信 API を上限まで使っていても、配信状況を確認する API の上限は減りません

ポーリング間隔

同じデータに対するポーリングは、1 秒以上の間隔を空けてください。完了を待つ場合は、間隔を徐々に広げる実装（指数バックオフ）を推奨します。

再試行

• 指数バックオフで実装してください。失敗するたびに待ち時間を 2 倍にし（1 秒 → 2 秒 → 4 秒 → 8 秒…）、さらに待ち時間へランダムなゆらぎ（ジッター）を加えます。一定の間隔で再試行すると、複数のプロセスが同じタイミングで再送し続けてリクエストが集中します。
• 冪等性キー（idempotency_key）を受け付けるエンドポイントでは、キーを変えないでください。同じキーで送り直せば二重に配信されることはありません。再試行時に新しいキーを使うと、先のリクエストが受け付けられていた場合に二重配信になります。
  • 既に受け付け済みのキーで再送した場合は 409 が返ります。二重配信は発生していないため、再試行を打ち切り、正常に受け付けられたものとして処理を進めてください。