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コールはリダイレクトに従いません。

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を付与します。個々のオブジェクトに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ドキュメントを参照してください。

User-Agentヘッダー

Brazeは、すべてのConnected ContentおよびWebhookリクエストに以下のようなUser-Agentヘッダーを含めます。

1
Braze Sender 75e404755ae1270441f07eb238f0faf25e44dfdc

ヒント

ハッシュ値は定期的に変更されることに注意してください。User-Agentでトラフィックをフィルタリングする場合は、Braze Senderで始まるすべての値を許可してください。

トラブルシューティング

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でない場合にレスポンスを処理する方法がありません。

Webhook.siteを使用して、Connected Contentの呼び出しのトラブルシューティングを行い、呼び出しで送信されるリクエストヘッダー、リクエストボディ、その他の情報に関する問題を診断することもできます。

1. Connected Contentの呼び出しのURLを、サイトで生成された一意のURLに切り替えます。
2. キャンペーンまたはキャンバスステップをプレビューしてテストし、このWebサイトにリクエストが届くことを確認します。

また、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
%}

よくある質問

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とキャッシュ設定が許可する場合、同一のリクエストは新しいアウトバウンドリクエストをトリガーするのではなく、キャッシュから提供されることがあります（詳細についてはレスポンスのキャッシュを参照してください）。