レート制限

Braze API インフラストラクチャは、顧客ベース全体で大量のデータを処理するように設計されています。このために、ワークスペースごとにAPI レート制限を適用します。

レート制限は、API が特定の期間に受信できるリクエストの数です。大規模システムにおける負荷ベースのサービス拒否インシデントの多くは、意図しないものです。これは、ソフトウェアや構成のエラーによるものです。悪意のある攻撃ではありません。レート制限は、このようなエラーが顧客からのBraze APIリソースを奪うことがないことを確認します。所定の時間内に送信されるリクエストが多すぎる場合、エラーレスポンスで429 というステータスコードが表示されることがあります。これは、レート制限に達したことを示しています。

リクエストタイプ別のレート制限

次の表に、さまざまなリクエストタイプのデフォルトのAPI レート制限を示します。これらのデフォルトの制限は、要求に応じて増やすことができます。詳細については、カスタマー・サクセス・マネージャーにお問い合わせください。

要求タイプ	デフォルトAPI レート制限
/users/track	リクエスト:1 分あたり 50,000 件のリクエスト。 バッチ処理:API リクエストごとに、75 個のイベント、75 個の購入、および75 個の属性。詳細については、ユーザーのトラック要求のバッチ処理を参照してください。
/users/export/ids	1 分あたり2500 件のリクエスト
/users/delete /users/alias/new /users/alias/update /users/identify /users/merge	エンドポイント間で共有される、1 分あたり 20,000 件のリクエスト。
/users/external_id/rename	1 分あたり1000 件のリクエスト
/users/external_id/remove	1 分あたり1000 件のリクエスト
/events/list	1,000 requests per hour, shared with the /purchases/product_list endpoint.
/purchases/product_list	1,000 requests per hour, shared with the /events/list endpoint.
/campaigns/data_series	50,000 requests per minute.
/messages/send	ブロードキャストコール(セグメントまたはConnected Audience のみを指定する場合) 1 分あたり250 件のリクエスト。それ以外の場合は、1 時間あたり250,000 件のリクエスト。
/campaigns/trigger/send	ブロードキャストコールに対する1 分あたり250 件のリクエスト(セグメントまたはConnected Audience のみを指定する場合)。それ以外の場合は、1 時間あたり250,000 件のリクエスト。
/canvas/trigger/send	ブロードキャストコール(セグメントまたはConnected Audience のみを指定する場合) 1 分あたり250 件のリクエスト。それ以外の場合は、1 時間あたり250,000 件のリクエスト。
/sends/id/create	1 日あたり100 件のリクエスト。
/subscription/status/set	1 分あたり5000 件のリクエスト
/preference_center/v1/{preferenceCenterExternalId}/url/{userId} /preference_center/v1/list /preference_center/v1/{preferenceCenterExternalId}	1 分あたり 1000 件のリクエスト (ワークスペースあたり)
/preference_center/v1 /preference_center/v1/{preferenceCenterExternalId}	1 分あたり10 件の要求(ワークスペースあたり)
/catalogs/{catalog_name} /catalogs /catalogs	エンドポイント間で共有される 1 分あたり 50 リクエスト。
/catalogs/{catalog_name}/items /catalogs/{catalog_name}/items /catalogs/{catalog_name}/items	エンドポイント間で共有される1 分あたり16,000 件のリクエスト。
/catalogs/{catalog_name}/items/{item_id} /catalogs/{catalog_name}/items/{item_id} /catalogs/{catalog_name}/items /catalogs/{catalog_name}/items/{item_id} /catalogs/{catalog_name}/items/{item_id}	エンドポイント間で共有される 1 分あたり 50 リクエスト。
/scim/v2/Users/{id} /scim/v2/Users?filter={userName@example.com} /scim/v2/Users/{id} /scim/v2/Users/{id}} /scim/v2/Users/	エンドポイント間で共有される、1 日あたり1 社あたり5000 件のリクエスト。

API 要求のバッチ処理

BrazeAPI はバッチ処理をサポートするように構築されています。バッチ処理を使用すると、Braze は1 回のAPI 呼び出しでできるだけ多くのデータを取り込むことができるため、多くのAPI 呼び出しを行う必要がありません。データを一度に1 回の呼び出しで処理するよりも、Braze でデータを一度に処理する方が効率的です。たとえば、1000 回のバッチAPI コールを処理すると、75,000 回の個別コールを処理するよりも少ないリソースが必要になります。バッチ処理は、1 時間に75,000 回を超えるコールが必要なアプリケーションでは非常に重要です。

ユーザートラック要求のバッチ処理

各/users/track リクエストには、最大75 個のイベントオブジェクト、75 個の属性オブジェクト、および75 個の購入オブジェクトを含めることができます。各オブジェクト(イベント、属性、購入アレイ)は、各1 人のユーザーを更新できます。これにより、1回の通話で最大225人のユーザを更新できます。また、1 つのユーザープロファイルを複数のオブジェクトで更新できます。

このエンドポイントに対して行われた要求は、通常、次の順序で処理を開始します。

1. 属性
2. イベント
3. 購入

バッチメッセージングエンドポイント要求

メッセージングエンドポイントへの単一のリクエストは、次のいずれかに到達できます。

• 最大50 個の特定のexternal_ids、それぞれ個別のメッセージパラメータを含む
• Braze ダッシュボードで作成された任意のサイズのセグメント。Braze ダッシュボードで指定されます segment_id
• リクエストで接続されたオーディエンスオブジェクトとして定義されている任意のサイズの追加のオーディエンスフィルタに一致するユーザ

レート制限の監視

Braze に送信された 1 つの API リクエストごとに、レスポンスヘッダーに以下の情報が返されます。

ヘッダ名	説明
X-RateLimit-Limit	指定した間隔で実行できるリクエストの最大数(レート制限)。
X-RateLimit-Remaining	現在のレート制限ウィンドウに残っている要求の数。
X-RateLimit-Reset	現在のレート制限ウィンドウがUTC エポック秒でリセットされる時間。

この情報は、Braze ダッシュボードではなく、API 要求に対する応答のヘッダーに意図的に含まれています。これにより、システムは、API とやり取りする際にリアルタイムでより効果的に反応できます。たとえば、X-RateLimit-Remaining の値が特定のしきい値を下回った場合、すべてのトランザクションメールが確実に送信されるように送信を遅くすることができます。または、ゼロに達した場合は、X-RateLimit-Reset で指定した時間が経過するまで、すべての送信を一時停止することができます。

API 制限についてご質問がある場合は、カスタマーサクセスマネージャーにお問い合わせいただくか、サポートチケット を開きます。

エンドポイント間の最適遅延

Braze API を連続して呼び出す場合、エンドポイント間の最適な遅延を理解することが重要です。エンドポイントが他のエンドポイントの正常な処理に依存している場合、問題が発生し、呼び出しが早すぎるとエラーが発生する可能性があります。たとえば、ユーザーに/user/alias/new エンドポイント経由でエイリアスを割り当て、そのエイリアスをヒットして/users/track エンドポイント経由でカスタムイベントを送信する場合、どのくらいの期間待機する必要がありますか?

通常の条件下では、データの整合性が実現するまでの時間は10 ～100ms (1/10 秒) です。ただし、その整合性の発生に時間がかかる場合があるため、エラーの可能性を最小限に抑えるために、後続の呼び出しの間に5 分の遅延を許可することをお勧めします。