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 のみをサポートしています。バナーの場合は、GET リクエストのみがサポートされます。詳細については、バナー用 Connected Content を参照してください。

エラーハンドリング

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コールの処理方法

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

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

メッセージで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は以下のIP範囲からConnected Contentリクエストを送信します。リストに記載されている範囲は、許可リストにオプトインされたすべてのAPIキーに自動的かつ動的に追加されます。

Brazeは、すべてのサービスに使用される予約済みIPセットを保有しており、特定の時点ですべてがアクティブであるとは限りません。これは、必要に応じてBrazeが別のデータセンターから送信したり、メンテナンスを行ったりしても、顧客に影響を与えないように設計されています。Connected Contentリクエストを行う際、Brazeは以下にリストされている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条件付きのバケットポリシーを追加する： バケットオブジェクトに対してs3:GetObjectをPrincipal: "*"で許可し、お使いのインスタンスのBrazeのIP範囲を使用するIpAddress条件を設定します。個々のオブジェクトにpublic-read 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リクエストでは、そのヘッダーを設定していない場合、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}}を使用して目的のネストされたフィールドを指定します。RESPONSE:{{sampleresult.data}}で期待される結果を出力することで、ネストされたJSONプロパティを確認できます。
• レスポンスステータスコードを確認する: レスポンスステータスコードは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 は、メッセージペイロードをレンダリングするために、受信者ごとに同じ Connected Content API 呼び出しを複数回行う場合があります。メッセージペイロードは、バリデーション、リトライロジック、またはその他の内部処理のために、受信者ごとに複数回レンダリングされることがあります。ただし、メッセージに反映される Connected Content 呼び出しは1回のみです。

リトライロジックが呼び出しで使用されていない場合でも、受信者ごとに Connected Content API 呼び出しが複数回行われることは想定される動作です。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 とキャッシュ設定が許可する場合、同一のリクエストは新しいアウトバウンドリクエストをトリガーする代わりにキャッシュから提供されることがあります（詳細についてはレスポンスのキャッシュを参照してください）。