トラブルシューティング

配信結果が想定と異なるときに参照するページです。まず症状ごとの確認ポイントを見て、原因となる動作の仕組みは下で確認してください。API側の原因は、開発チームと一緒にAPI連携ガイドを確認してください。

保存が拒否されるケースの表を順に確認してください。

• メッセージに書いたフィールド名がレスポンスと完全に一致しているか（大文字・小文字を含む）
• POSTでJSONを受け取るAPIの場合、:content_type application/json を書いたか
• URLに入れた値が特殊文字のせいで崩れていないか（url_encode）
• URLをコピーして貼り付けたときに、見えない空白が混ざっていないか
• サーキットブレーカーが作動していなかったか
• APIがJSONヘッダー・2xxレスポンス・2秒・1MBの条件を満たしているか（開発チームに確認）

• 認証情報の名前・方式・許可ドメインがリクエストURLと合っているか
• {% abort_message %} が実行されたか（失敗理由「パーソナライズ構文による中断」）
• 配信時にLiquidのレンダリングエラーが発生したか

• サーキットブレーカーが作動していなかったか
• URLが外部からアクセス可能か、標準ポート（80・443）か
• :headers がJSONオブジェクト形式か
• メッセージが実際に配信されたか（保存の拒否や配信失敗ではないか）

• FlareLaneの送信元IPを許可リストに追加したか
• User-Agent: FlareLane-ConnectedContent/1.0 のリクエストをブロックしていないか

• ディレクティブの数だけ呼び出されます。フィールドごとに別々に数えます。
• 処理中のエラーで再処理されると、同じ受信者に対して再度呼び出されることがあります。
• レスポンスの再利用（キャッシュ）によって呼び出しが減ることがあります。再利用の基準はレスポンスの再利用を設定するをご確認ください。

多くの場合は空欄のまま配信されますが、その受信者にまったく配信されないケースもあります。

APIの失敗が続くと、FlareLaneはそのAPIサーバーをしばらく呼び出さず、空欄のまま配信します。障害が起きているサーバーの回復を助け、呼び出しのたびに配信が2秒ずつ遅れるのを防ぐためです。default: で代わりの文言を書いておけば備えられます。