Connected Content APIの呼び出しを行う

Connected Contentを使用すると、APIでアクセス可能な情報をユーザーに送信するメッセージに直接挿入できます。Webサーバーから直接、または公開されているAPIからコンテンツを取得できます。

このページでは、Connected Content APIの呼び出し方法、高度なConnected Contentのユースケース、エラー処理などについて説明します。

Connected Contentの呼び出し量について

重要

1回の送信は1回のConnected Contentの呼び出しと等しくありません。Brazeはメッセージ送信とConnected Contentリクエストの間の1:1の比率を保証しません。システムは、呼び出し回数を最小限に抑えることよりも、正しいメッセージのレンダリングと配信を優先するように設計されています。エンドポイントは、受信者数や送信メッセージ数よりも多くのリクエストを処理できるように構築する必要があります。

Brazeは、受信者1人あたり同じConnected Content APIの呼び出しを複数回行う場合があります。一般的な理由は以下のとおりです。

• 複数パートのメール： 1通のメールで、HTML本文、プレーンテキスト本文、Accelerated Mobile Pages（AMP）バージョン（存在する場合）のそれぞれに対して個別のレンダリングパスがトリガーされることがあります。各パスでそのパートのConnected Contentがトリガーされるため、1人の受信者が複数の同一または類似の呼び出しを生成する可能性があります。
• バリデーションとリトライ： メッセージペイロードは、バリデーション、リトライロジック、その他の内部目的のために、受信者1人あたり複数回レンダリングされることがあります。
• チャネルの動作： Connected Contentはメッセージがレンダリングされるときに実行されます。アプリ内メッセージの場合、メッセージはインプレッション時にレンダリングされます。

ログで送信数や受信者数よりも多くのConnected Contentの呼び出しが確認される場合、その動作は想定どおりです。負荷の軽減とスケーリングの計画については、大量エンドポイントのベストプラクティスを参照してください。

Connected Content コールを送信する

Connected Content コールを送信するには、{% connected_content %} タグを使用します。このタグでは、:save を使用して変数を割り当てたり宣言したりできます。これらの変数の要素は、後でメッセージ内で Liquid を使って参照できます。

API コールの内訳

次の例では、Sunrise-Sunset API を使用して、今日の日の出時刻をメッセージに含めています。

1
2
{% connected_content https://api.sunrise-sunset.org/v2?lat=40.7128&lng=-74.0060&date=today :save result %}
Hi there, today's sunrise in NYC is at {{result.sunrise}}.

各部分の役割は次のとおりです。

Sunrise-Sunset API レスポンスの仕組み

このエンドポイントは、sunrise、sunset、tzid などのトップレベルフィールドを含む JSON を返します。時刻はデフォルトでその場所のタイムゾーンで返されます（この例ではニューヨーク時間）。

たとえば、レスポンスの形式は次のようになります。

1
2
3
4
5
6
{
  "date": "2026-07-23",
  "tzid": "America/New_York",
  "sunrise": "2026-07-23T05:42:11-04:00",
  "sunset": "2026-07-23T20:21:32-04:00"
}

API レスポンスを Liquid にマッピングする

レスポンスは result として保存されるため、そのオブジェクトから各フィールドを直接参照できます。

1
2
3
{{result.sunrise}}
{{result.sunset}}
{{result.tzid}}

Connected Content から JSON を保存する場合は、常にこのパターンを使用します。

1. :save で API レスポンスを保存します。
2. JSON レスポンスから必要なフィールドを見つけます。
3. Liquid で saved_variable.field_name として参照します。

変数を追加する

Connected Content リクエストを行う際に、URL 文字列の変数としてユーザープロファイル属性を含めることもできます。

たとえば、ユーザーのメールアドレスと ID に基づいてコンテンツを返す Web サービスがあるとします。アットマーク（@）などの特殊文字を含む属性を渡す場合は、次のメールアドレス属性の例に示すように、Liquid フィルター url_param_escape を使用して、URL で許可されていない文字を URL に適した形式のエスケープバージョンに置き換えてください。

1
2
3
Hi, here are some articles that you might find interesting:

{% connected_content http://www.yourwebsite.com/articles?email={{${email_address} | url_param_escape}}&user_id={{${user_id}}} %}

注

属性値は、Braze の Liquid 構文で正しく動作するために、${} で囲む必要があります。

Connected Content リクエストでは、GET リクエストと POST リクエストのみがサポートされています。

エラー処理

URL が利用できず 404 ページに到達した場合、Braze はその箇所に空の文字列をレンダリングします。URL が HTTP 500 または 502 ページに到達した場合、URL はリトライロジックで失敗します。

エンドポイントが JSON を返す場合、connected の値が null かどうかを確認し、条件付きでメッセージを中止することで検出できます。Braze はポート 80 (HTTP) および 443 (HTTPS) で通信する URL のみを許可します。

異常ホスト検出

Connected Content は、ターゲットホストが著しい低速化や過負荷の高い発生率を経験し、タイムアウト、過剰なリクエスト、または Braze がターゲットエンドポイントとの通信を正常に行えないその他の結果が生じた場合に検出する、異常ホスト検出メカニズムを採用しています。これは、ターゲットホストの問題の原因となっている可能性のある不要な負荷を軽減するためのセーフガードとして機能します。また、Braze インフラの安定化とメッセージング速度の維持にも役立ちます。

ターゲットホストが著しい低速化や過負荷の高い発生率を経験した場合、Braze はターゲットホストへのリクエストを一時的に 1 分間停止し、代わりに失敗を示すレスポンスをシミュレートします。1 分後、Braze は少数のリクエストを使用してホストの正常性をプローブし、ホストが正常であることが確認された場合、フルスピードでリクエストを再開します。ホストがまだ異常な場合、Braze はさらに 1 分待ってから再試行します。

異常ホスト検出器によってターゲットホストへのリクエストが停止された場合、Braze はエラーレスポンスコードを受信した場合と同様に、メッセージのレンダリングと Liquid ロジックの実行を続行します。異常ホスト検出器によって停止された Connected Content リクエストを確実にリトライしたい場合は、:retry オプションを使用してください。:retry オプションの詳細については、Connected Content のリトライを参照してください。

異常ホスト検出が問題を引き起こしていると思われる場合は、Braze サポートにお問い合わせください。

注

Connected Content に使用する特定の URL を許可リストに追加できます。この機能を利用するには、カスタマーサクセスマネージャーにお問い合わせください。

ヒント

一般的なエラーコードの詳細については、Webhook と Connected Content リクエストのトラブルシューティングを参照してください。

レート制限 (429) と異常ホスト検出の違い

以下は異なるメカニズムです。

• 429 Too Many Requests: エンドポイント（または上流のサービス）がこのレスポンスを返しています。これは、サーバーまたはミドルウェアが独自のレート制限を持っていることが多いため、トラフィックを拒否していることを意味します。Braze は Connected Content に個別のレート制限を適用しません。Connected Content のリクエスト量は、メッセージ配信速度のレート制限に直接比例します。メッセージは受信者ごとに複数回レンダリングされる可能性があるため（例えば、メールの HTML、プレーンテキスト、AMP）、Connected Content リクエストの数はそのレート制限を超える場合があります。設定した1分あたりのメッセージ数以下になるとは想定しないでください。429 エラーが発生する場合は、予想されるリクエスト量を処理できるようにエンドポイントまたはミドルウェアをスケールするか、キャンペーンまたはキャンバスの配信速度のレート制限を下げて、1分あたりに送信されるメッセージ（つまり Connected Content 呼び出し）の数を減らしてください。
• 異常ホスト検出: 1 分間のウィンドウ内で高い発生率と量の失敗が発生した後にトリガーされる、Braze 側のセーフガードです。失敗カウントには 408、429、502、503、504、529 のステータスコードが含まれます。トリガーされると、Braze はそのホストへのリクエストを一時的に停止し、失敗レスポンスをシミュレートします。これはお客様独自のレート制限とは独立しています。検出しきい値と詳細については、Webhook と Connected Content リクエストのトラブルシューティングを参照してください。異常ホスト検出のトリガーを回避するには、Connected Content の呼び出し量を理解するおよび大量エンドポイントのベストプラクティスで説明されている呼び出し量をエンドポイントが処理できることを確認してください。

効率的なパフォーマンスの確保

Brazeは非常に高速にメッセージを配信するため、コンテンツの取得時にオーバーロードしないよう、サーバーが数千の同時接続を処理できることを確認してください。パブリックAPIを使用する場合は、APIプロバイダーが設定しているレート制限に違反しないことを確認してください。Brazeはパフォーマンス上の理由から、サーバーのレスポンス時間が2秒未満であることを要求しています。サーバーのレスポンスに2秒以上かかる場合、コンテンツは挿入されません。

エンドポイントのキャパシティ計画と呼び出し量の削減については、大量エンドポイントのベストプラクティスを参照してください。

知っておくべきこと

• Brazeは API コールに対して課金せず、所定のデータポイント使用量にもカウントされません。
• Connected Contentのレスポンスには1 MBの制限があります。
• Connected Contentはメッセージがレンダリングされるときに実行されます。アプリ内メッセージの場合、メッセージはインプレッション時にレンダリングされます。
• Connected Contentコールはリダイレクトに従いません。2xx レスポンスのみが成功として扱われます。エンドポイントが3xxリダイレクト（例: 301や302）を返す場合、Brazeはリダイレクト先の最終URLに従いません。症状やトラブルシューティング手順については、エンドポイントがリダイレクトを返すとConnected Contentが失敗するのはなぜですか？を参照してください。

Connected Contentコールの処理方法

単一のメッセージテンプレート内のConnected Contentコールは、Liquidレンダリング中に順番に（上から下へ）実行されます。つまり、下流のコールは上流のコールで設定された変数を参照できます。この例では、最初のコールがユーザーデータを取得し、2番目のコールがそのデータを使用してプリファレンスを取得します。

1
2
{% connected_content https://api.example.com/user :save user_data %}
{% connected_content https://api.example.com/preferences?user_id={{user_data.id}} :save preferences %}

グローバル送信とリクエストボリューム

Connected Contentコールは単一メッセージ内では順番に実行されますが、メッセージはキャンペーンやキャンバス全体で並列に送信されます。大量送信では、ピーク送信期間中にエンドポイントに対して大量のリクエストトラフィックが発生する可能性があります。このトラフィックの管理とスロットリング（ワークスペースのメッセージングレート制限、配信速度のレート制限、キャッシュなど）については、大量エンドポイントのベストプラクティスを参照してください。

大量送信エンドポイントのベストプラクティス

メッセージでConnected Contentを使用し、大量に送信する場合は、受信者数や送信数を超えるリクエストを想定して計画してください。

• ピーク負荷を見積もる: エンドポイントやミドルウェアのサイジングには、控えめな倍率を使用してください。Connected Contentのリクエストは、受信者数やメッセージ送信数を超えることがあります。たとえばメールの場合、1人の受信者に対して複数の呼び出し（HTML、プレーンテキスト、AMP）が発生する可能性があるため、受信者数 × 2 または × 3 が控えめな見積もりとしてよく使用されます。
• 適切な場合はキャッシュを使用する: GETリクエストはデフォルトでキャッシュされます。POSTリクエストの場合は、レスポンスが一定期間再利用できる場合（たとえば、リクエストごとに変わらないトークンやコンテンツ）に :cache_max_age を追加してください。レスポンスのキャッシュおよび次のセクションのPOSTキャッシュに関するFAQを参照してください。
• メッセージのレート制限を設定する: ワークスペースのメッセージングレート制限およびキャンペーンやキャンバスの配信速度のレート制限は、Connected Contentのリクエスト量を間接的に制限します。Braze自体がConnected Contentをレート制限することはありません。Connected Contentのリクエストはメッセージと1対1ではないため、これらは近似的な手段であり、完全なものではありません。エンドポイントが処理できる範囲内にメッセージ（ひいてはConnected Content）のボリュームを抑えるために活用してください。
• 冪等性とリトライを考慮した設計にする: Brazeは1人の受信者に対してエンドポイントを複数回呼び出す場合があります。エンドポイントが重複リクエストを受けても、不正な副作用なく処理できるようにしてください。

認証タイプ

ベーシック認証の使用

URL にベーシック認証が必要な場合、Braze は API 呼び出しで使用するベーシック認証の認証情報を保存できます。既存のベーシック認証の認証情報を管理したり、新しい認証情報を追加したりするには、設定 > Connected Content に移動します。

新しい認証情報を追加するには、認証情報を追加 > ベーシック認証を選択します。

認証情報に名前を付け、ユーザー名とパスワードを入力します。

その後、トークンの名前を参照することで、API 呼び出しでこのベーシック認証の認証情報を使用できます。

1
Hi there, here is some fun trivia for you!: {% connected_content https://yourwebsite.com/random/trivia :basic_auth credential_name %}

注

認証情報を削除する場合、その認証情報を使用しようとする Connected Content 呼び出しはすべて中止されることに注意してください。

保存された認証情報は、Braze がメッセージをレンダリングする際に {% connected_content %} リクエストに適用されます。Webhook ステップで設定されたプライマリ HTTP リクエストには適用されません。その呼び出しのためにシークレットを取得する必要がある場合は、リクエストヘッダーを使用するか、Webhook のヘッダーまたはボディフィールド内に {% connected_content %} タグを使用してください。

トークン認証の使用

Braze の Connected Content を使用する際、一部の API ではユーザー名とパスワードの代わりにトークンが必要になる場合があります。Braze はトークン認証のヘッダー値を保持する認証情報も保存できます。

トークン値を保持する認証情報を追加するには、認証情報を追加 > トークン認証を選択します。次に、API 呼び出しヘッダーのキーと値のペアと許可されたドメインを追加します。

その後、認証情報名を参照することで、API 呼び出しでこの認証情報を使用できます。

1
2
3
4
5
6
7
8
9
{% assign campaign_name="New Year Sale" %}
{% connected_content
     https://api.endpoint.com/your_path
     :method post
     :auth_credentials token_credential_abc
     :body campaign={{campaign_name}}&customer={{${user_id}}}&channel=Braze
     :content_type application/json
     :save publication
%}

Open Authentication（OAuth）の使用

一部の API 設定では、アクセスしたい API エンドポイントの認証に使用できるアクセストークンの取得が必要です。

ステップ 1: アクセストークンを取得する

次の例は、アクセストークンを取得してローカル変数に保存し、後続の API 呼び出しの認証に使用する方法を示しています。:cache_max_age パラメーターを追加して、アクセストークンの有効期間に合わせ、アウトバウンドの Connected Content 呼び出し数を削減できます。詳細については、設定可能なキャッシュを参照してください。

1
2
3
4
5
6
7
8
9
10
{% connected_content
     https://your_API_access_token_endpoint_here/
     :method post
     :auth_credentials access_token_credential_abc
     :headers {
       "Content-Type": "YOUR-CONTENT-TYPE"
     }
     :cache_max_age 900
     :save token_response
%}

注

トークンエンドポイントが application/x-www-form-urlencoded を期待し、認証情報を :body で渡す場合、パラメーター値の特殊文字を URL エンコードしてください。たとえば、スラッシュ（/）は %2F に、プラス記号（+）は %2B になります。エンコードされていない特殊文字があると、OAuth トークンリクエストが失敗する場合があります。

ステップ 2: 取得したアクセストークンを使用して API を認可する

トークンが保存されたら、後続の Connected Content 呼び出しに動的にテンプレート化してリクエストを認可できます。

1
2
3
4
5
6
7
8
9
{% connected_content
     https://your_API_endpoint_here/
     :headers {
       "Content-Type": "YOUR-CONTENT-TYPE",
       "Authorization": "{{token_response}}"
     }
     :body key1=value1&key2=value2
     :save response
%}

認証情報の編集

認証タイプの認証情報名を編集できます。

• ベーシック認証の場合、ユーザー名とパスワードを更新できます。以前に入力したパスワードは表示されませんのでご注意ください。
• トークン認証の場合、ヘッダーのキーと値のペアと許可されたドメインを更新できます。以前に設定されたヘッダー値は表示されませんのでご注意ください。

Connected Content IPアローリスティング

Connected Contentを使用するメッセージがBrazeから送信されると、Brazeサーバーは自動的に顧客またはサードパーティのサーバーにネットワークリクエストを行い、データを取得します。IPアローリスティングを使用すると、Connected Contentリクエストが実際にBrazeから送信されていることを確認でき、セキュリティの層を追加できます。

BrazeはConnected Contentリクエストを以下のIP範囲から送信します。リストされた範囲は、アローリスティングにオプトインされたAPIキーに自動的かつ動的に追加されます。

Brazeには、すべてのサービスに使用される予約済みのIPセットがあり、特定の時点ですべてがアクティブであるとは限りません。これは、必要に応じて、Brazeが顧客に影響を与えることなく、別のデータセンターから送信したりメンテナンスを行ったりできるように設計されています。BrazeはConnected Contentリクエストを行う際に、以下にリストされたIPの1つ、一部、またはすべてを使用する場合があります。

Connected Contentリクエストが一貫して 403 Forbidden を返し、認証が正しく設定されている場合は、リクエストを受信するサーバーでこれらのIPをアローリストに追加してください。403 は権限不足や無効な認証情報を示す場合もあるため、ネットワークと認証の両方の設定を確認してください。Webhook固有のガイダンスについては、403 ForbiddenとIPアローリスティングを参照してください。

• united states (us)
• european union (eu)
• australia (au)
• indonesia (id)
• japan (jp)
• south korea (kr)

Amazon S3でのIPアローリスティングの使用

Connected Contentを使用してAmazon S3からファイルを取得する場合、BrazeのIPアドレスからの非認証HTTP GET リクエストを許可するようにバケットを設定します。

1. IP条件付きのバケットポリシーを追加する: Principal: "*" と、インスタンスのBrazeのIP範囲を使用する IpAddress 条件を指定して、バケットオブジェクトに s3:GetObject を付与します。個々のオブジェクトにパブリック読み取りACLを設定する必要はありません。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::your-bucket-name/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": ["{YOUR_BRAZE_IP_RANGE}"]
        }
      }
    }
  ]
}

{YOUR_BRAZE_IP_RANGE} をConnected Content IPアローリスティングにリストされているインスタンスのBrazeのIP範囲に置き換えます。aws:SourceIp 配列に個別の値として1つ以上の範囲を追加できます。

2. S3ブロックパブリックアクセス設定を確認する: Principal: "*" を使用するバケットポリシーは、IP条件が設定されていても、AWSによってパブリックアクセスとして扱われます。ACLベースのパブリックアクセスをブロックしたまま、バケットポリシーベースのパブリックアクセスを許可する必要がある場合があります。

3. Connected ContentタグでS3オブジェクトURLを使用する: 標準のS3 URLでオブジェクトを参照します（例：https://your-bucket.s3.amazonaws.com/path/to/object.json）。

バケットポリシーと条件キーの詳細については、AWSドキュメントを参照してください。

送信リクエストヘッダー

Brazeは、送信されるConnected Contentリクエストに以下のヘッダーを追加します。ほとんどのヘッダーは、タグ内でまだ指定されていない場合にのみ設定されます。:headers、認証情報、またはタグオプションで指定したヘッダーは、指定した通りに送信されます。

Webhookリクエストでは、User-Agent ヘッダーを設定していない場合、Braze Sender で始まる User-Agent も送信されます。

トラブルシューティング

Connected Contentの呼び出しが正しくレンダリングされない、またはまったくレンダリングされない場合は、以下の項目を確認してください。

• ライブリクエストとレスポンスを検査する: プレビューとテストのConnected Contentデバッガーを使用します。
• Connected Contentの呼び出しが行われたことを確認する: メッセージング履歴タブで呼び出しが行われたかどうかを確認できます。単一のConnected Contentリクエストをテスト送信することもできます。
• PostmanまたはCURLリクエストで想定どおりのリクエストが成功するか検証する: リクエストが機能してレスポンスが返される場合は、リクエストの詳細（ヘッダーを含む）を比較してください。ヘッダーがダブルクォーテーション付きのキーと値のペアでキャプチャされていることを確認してください。
• 認証が正しく処理されていることを検証する: :basic_auth/:auth_credentialsオプションが使用されており、Connected Contentの認証がConnected Contentワークスペース設定に追加されていることを確認してください。Connected Content URLには認証以外のヘッダーが必要な場合があり、それらを入力する必要があります。
• データが期待される形式であることを検証する: レスポンスボディについて、Brazeは有効なJSONをLiquidオブジェクトにパースします。それ以外の場合、レスポンスはプレーンテキスト（HTMLを含む）として扱われます。:content_typeオプションはリクエストの送信Content-TypeおよびAcceptヘッダーを設定しますが、レスポンスのパースには影響しません。リクエストの:bodyについて、JSONにスペースが含まれている場合は、JSONボディの提供セクションのガイダンスに従ってください。
• データが正しくパースされたことを確認する: Liquidが期待されるフィールドを正しく参照しているか確認してください。ネストされたJSONの場合は、{{sampleresult.data[0].sample_field}}を使用して目的のネストされたフィールドを指定します。ネストされたJSONプロパティは、RESPONSE:{{sampleresult.data}}で期待される結果を出力することで確認できます。
• レスポンスステータスコードを確認する: レスポンスステータスコードは2XXコードである必要があります。Connected Contentでは、コードが2XXでない場合にレスポンスを利用する方法はありません。

プレビューとテストでプレビューを生成し、詳細を表示を選択してConnected Contentデバッガーを開きます。デバッガーには、Connected Contentタグからのヘッダーが一覧表示されます。Brazeが送信リクエストに追加するヘッダーについては、送信リクエストヘッダーを参照してください。

また、Liquidタグにエンドポイントが期待するパラメーター（例: :method、:headers、:content_type、:body、必要に応じて:basic_auth）が含まれていることも確認できます。保存されたJSONオブジェクトのHTTPステータスコードキーに依存している場合、エンドポイントはJSONオブジェクトと2XXステータスを返す必要があります。

ホストからのエラーレートが高い場合は、異常ホスト検出およびConnected Contentの呼び出しボリュームを確認してください。

メールPOSTリクエストでのアンパサンドエンコーディング

メールメッセージでは、HTMLパースにより{% capture %}ブロック内のアンパサンド（&）が自動的に&に変換されます。application/x-www-form-urlencodedのPOSTリクエストでは、これによりリクエストがパラメーター名にamp;プレフィックスを付けて送信される（例: amp;username）ため、API呼び出しが失敗する可能性があります。

この問題を回避するには、replaceフィルターを使用して、ボディを:bodyに渡す前にamp;プレフィックスを削除します。

1
2
3
4
5
6
7
8
9
{% capture body_with_amps %}
grant_type=client_credentials&username=test&password=test
{% endcapture %}
{% connected_content https://api.example.com/token
   :method post
   :body {{body_with_amps | replace: "amp;", ""}}
   :content_type application/x-www-form-urlencoded
   :save token
%}

よくある質問

エンドポイントがリダイレクト（301 または 302）を返すと Connected Content が失敗するのはなぜですか？

リダイレクトにより、Connected Content がプレビューや送信時に空白で表示されたり、メッセージアクティビティログに HTTP ステータスコード 301 または 302 のエラーが記録されたりすることがあります。Postman やその他のクライアントはリダイレクトを自動的にフォローすることが多いため、Postman では動作する URL が Braze では失敗することがあります。

エンドポイントを設定して、Braze が呼び出す URL でレスポンスボディを含む 2xx レスポンス（通常は 200）を返すようにしてください。その URL 自体がリダイレクトを返す場合は、最終的なリダイレクト先 URL に置き換えてください。

コンテンツが空白で表示される場合の関連チェックについては、Connected Content がレスポンスボディを返さないを参照してください。

Connected Content の呼び出しがユーザー数や送信数よりも多いのはなぜですか？

Braze は、メッセージペイロードをレンダリングするために、受信者1人あたり同じ Connected Content API 呼び出しを複数回行うことがあります。メッセージペイロードは、バリデーション、リトライロジック、その他の内部目的のために、受信者1人あたり複数回レンダリングされることがあります。ただし、Connected Content の呼び出しのうちメッセージに反映されるのは1回のみです。

リトライロジックが呼び出しで使用されていない場合でも、Connected Content API 呼び出しが受信者1人あたり複数回行われることは想定される動作です。Connected Content を含むメッセージにレート制限を設定するか、メッセージ送信あたり複数回の Connected Content 呼び出しが行われることを考慮した予想ボリュームを処理できるようサーバーを構成することをお勧めします。

詳細と軽減策については、Connected Content の呼び出しボリュームについてと大量トラフィックのエンドポイントに関するベストプラクティスを参照してください。

Connected Content でレート制限はどのように機能しますか？

Connected Content には独自のレート制限はありません。代わりに、レート制限はメッセージ送信レートに基づいています。送信されるメッセージよりも Connected Content の呼び出しが多い場合は、メッセージングのレート制限を意図する Connected Content のレート制限よりも高く設定することをお勧めします。

キャッシュの動作はどうなっていますか？

GET リクエストはデフォルトでキャッシュされます（レスポンスのキャッシュを参照）。POST リクエストはデフォルトではキャッシュされませんが、Connected Content の呼び出しに :cache_max_age を追加することでキャッシュを有効にできます。これにより、同じ POST（例えばトークンやコンテンツのリクエスト）がキャッシュウィンドウ内で繰り返し行われる場合のエンドポイント負荷を軽減できます。

1
{% connected_content https://api.example.com/token :method post :body grant_type=client_credentials :cache_max_age 900 :save token %}

キャッシュは重複する Connected Content の呼び出しを削減するのに役立ちますが、ユーザーあたり1回の呼び出しになることが保証されるわけではありません。キャッシュの期間は5分から4時間です。詳細については、レスポンスのキャッシュを参照してください。

Connected Content の HTTP デフォルト動作は何ですか？

デフォルトでは、Connected Contentは GET HTTPリクエストのContent-TypeヘッダーをAccept: */*付きのapplication/jsonに設定します。別のコンテンツタイプが必要な場合は、タグに:content_type your/content-typeを追加して明示的に指定してください。Brazeは、指定したタイプにContent-TypeヘッダーとAcceptヘッダーの両方を設定します。

1
{% connected_content https://api.sunrise-sunset.org/v2?lat=40.7128&lng=-74.0060&date=today :content_type application/json %}

デフォルトでは、Connected Contentは指定されたURLにHTTP GETリクエストを送信します。代わりにPOSTリクエストを行うには、:method postを指定します。

オプションで:bodyの後にkey1=value1&key2=value2&...形式のクエリ文字列またはキャプチャされた値への参照を指定することで、POSTボディを提供できます。Content-Typeのデフォルトはapplication/x-www-form-urlencodedです。:content_type application/jsonを指定し、key1=value1&key2=value2のようなフォームURLエンコードされたボディを提供すると、Brazeは送信前に自動的にボディをJSONエンコードします。

また、Connected ContentはデフォルトではPOST呼び出しをキャッシュしません。Connected ContentのPOST呼び出しに:cache_max_ageを追加することで、この動作を変更できます。

• デフォルトのcontent-type
• application/json content-type

1
{% connected_content https://example.com/api/endpoint :method post :body key1=value1&key2=value2 %}

1
{% connected_content https://example.com/api/endpoint :method post :body key1=value1&key2=value2 :content_type application/json %}

同じ Connected Content の呼び出しを複数の場所で使用するとどうなりますか？

各 Connected Content タグは、複数のタグが同じ URL とパラメーターを使用している場合でも個別に評価されます。URL とキャッシュ設定が許可する場合、同一のリクエストは新しいアウトバウンドリクエストをトリガーするのではなくキャッシュから提供されることがあります（詳細はレスポンスのキャッシュを参照してください）。