TwilioがAPIリクエストに対してError 429(英語)が発生する場合、これは同時APIリクエストの最大数に達したことを意味します。 このガイドでは、APIのリクエストを必要最低限に絞りError 429 レスポンスを回避するためのベストプラクティスを提案します。
不必要なフェッチングを減らす
当社のREST APIに対して多数のHTTP GETリクエストを送信している場合、以下のうちの1つ以上をご検討ください。
- 利用するリソースエンドポイントのアプリケーションに
StatusCallBackリクエストを実装してください。Twilioのコールバックレスポンスを保存することで、Twilioプラットフォームに追加のGETリクエストを行う代わりに、ご自身のローカルでサーバに問い合わせることができるようになります。以下は、アプリケーションにコールバックを追加するための2つの例です。 - Debugger Webhookを実装し、選択したエラーしきい値で自動的にサーバーに書き込み、追加のフェッチの必要性を低減します。
- 通話録音やメディアなどのデータをTwilioから自分のサーバーに移動します。データの移動完了後、必要ない場合はTwilioサーバに保存されているデータを削除してください。御社・御社の顧客間のプライバシー、セキュリティ、およびコンプライアンスのために推奨されるビジネスプラクティスであり、加えてTwilioの毎月のストレージコストを削減できます。
指数関数的バックオフによるリトライの実装
APIリクエストがError 429のレスポンスを受け取った場合、このリクエストは処理されません。Error 429のレスポンスがあるリクエストは、常に安全に再試行できます。ここでは、主要なクラウドプロバイダーから、指数関数的バックオフによる再試行のベストプラクティスについて説明したドキュメントを掲載しています。
- Google - 指数関数的バックオフの実装: https://cloud.google.com/iot/docs/how-tos/exponential-backoff
- Amazon - AWSでのエラーリトライと指数関数的バックオフ: https://docs.aws.amazon.com/general/latest/gr/api-retries.html
- Microsoft - 指数関数的バックオフの実装 : https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/implement-retries-exponential-backoff
さらなるサポートが必要な場合
両方のベストプラクティスを実施したにもかかわらず、エラー429が発生する場合は、該当するユースケース情報を添えて、弊社サポートチームまでご連絡ください。