オンプレミスAPIを終了します。詳細と次世代クラウドAPIへの移行方法については、オンプレミスAPIの終了のドキュメントを参照してください。
オンプレミスAPI: よくある質問
プラットフォームの障害に関する最新情報については、WhatsApp Businessプラットフォームステータスのページをご覧ください。
スタートガイド
WhatsAppは、ビジネスAPIユーザーが自分で制御するサーバー上のAPIエンドポイントを管理する場合、それらのユーザーとの通信はエンドツーエンドで暗号化されていると見なします。これは、エンドポイント間でコンテンツへのサードパーティアクセスがないためです。
一部の組織は、WhatsApp Business APIエンドポイントの管理をサードパーティのビジネスソリューションプロバイダーに委任していることがあります。その場合も、通信では同じSignalプロトコル暗号化が使用されます。しかし、WhatsApp Business APIユーザーがエンドポイントの管理をサードパーティに委任しているため、WhatsAppはこれらのメッセージがエンドツーエンド暗号化されているとは見なしません。これは、2021年中に、FacebookがホストするAPIのクラウドベースバージョンを利用している事業者にも適用される予定です。
さらに、WhatsApp Business APIクライアントへの呼び出しでHTTPSを使用している場合、その(バックエンドクライアントからWhatsApp Business APIクライアントへの)データはSSLで暗号化されます。
詳しくは、WhatsAppの暗号化の概要に関するテクニカルホワイトペーパーをご覧ください。
いいえ。インスタンスで使用できるアカウントは1つのみです。2つ目のテストアカウントが必要な場合、2つ目のインスタンスには必ず別の番号を使用してください。
いいえ！どんな時でも、単一の電話番号で実行できるのは1つのインスタンスのWhatsApp Business APIクライアントだけです。2つ目のインスタンスを登録すると、すぐに1つ目のインスタンスは解除され、失敗します。WhatsAppでは、この問題を適切に解決するべく取り組んでいます。最新情報は随時通知されます。
WhatsApp BusinessオンプレミスAPIクライアントの場合、ビジネスとカスタマー間で送信されたメッセージを復号するためのキーを保管するデータベースが必要になります。WhatsAppのすべてのメッセージは、送信者と受信者のキーで暗号化されています。カスタマーのキーはカスタマーのモバイルデバイスに保存され、ビジネスのキーはそのビジネスのデータベースに保存されます。詳しくは、WhatsAppのセキュリティをご覧ください。
Metaがビジネスのデータベースをホストしてる場合、WhatsApp BusinessクラウドAPIを代替として使用できます。クラウドAPIを使用すれば、自社サーバーをホストする経費をかけずにWhatsApp Business APIを実装できます。詳しくはこちら。
いいえ。現在のところ、同じWhatsApp Business APIクライアント設定で複数の電話番号を運用する手段はありません。将来的にこの問題を解決するため、適切なソリューションの開発が行われています。
インストール
もちろんです。デフォルトでは、WhatsAppビジネスAPIクライアントは、ポート5222経由でchatdを使用して通信を試みます。最高のエクスペリエンスを実現するには、すべてのアウトバウンドトラフィックに対してポート5222をオープンしてください。トラフィックはデータセンターからのみ送信されるため、セキュリティの問題は生じません。
ポート5222をオープンできない場合、WhatsAppビジネスAPIクライアントはポート443の使用を試みます。ファイアウォールまたはプロキシが接続を終了する問題が解決しない場合は、ダイレクトサポートを通じてデバッグに関する質問を送信し、WhatsAppチームと連絡を取ってください。
いいえ。 WhatsApp Business API Clientは、WhatsAppサーバーのポート5222または443へのアウトバウンドTCP接続を開きます。TCPトラフィックは、この長期接続を介して行われます。通常、ファイアウォールはこれを「アウトバウンドトラフィックと確立済みトラフィック」の許可として分類します。もちろん、いったん接続が確立すればパケットは双方向に送られますが、接続開始はWhatsAppビジネスAPI Client側から行われるため、インバウンド接続を許可するルールは必要ありません。
要件は、データ通信量や状況に応じて異なります。このソリューションは、インターネットに接続されていてDockerが実行されているものであれば、どのようなマシンでも実行できます。たとえば、ノートパソコンで簡単なテストを実行できます。
シングルインスタンスの本番用サーバー設定では、少なくとも250 GB SSD、16 GB RAM、4コアのCPUをおすすめします。HDDは、負荷がかかった場合に入出力速度がボトルネックになるのでおすすめしません。
マルチコネクトの本番用サーバー設定では、Coreapp/Master/Webappそれぞれのコンテナに対して少なくとも50 GB SSD、4 GB RAM、2コアのCPUをおすすめします。
多くの場合、データベースは、コアコンテナやWebコンテナとは別の物理サーバーで実行する必要があります。データベースサーバーとコンピュートマシンの間の遅延は、数ミリ秒以内である必要があります。
この設定では、毎秒20件のメッセージ送信がサポートされます。
MySQL 5.7.x、PostgreSQL 9.5.x、9.6.x、10.xが必要です。以前のバージョンを使用すると、Unable to initialize config storeエラーが発生します。
Docker MySQLガイドにしたがって、Dockerを使用してMySQLをローカルにセットアップします。
Docker PostgreSQLガイドにしたがって、Dockerを使用してPostgreSQLをローカルにセットアップします。
多くの場合、データベースは、コアコンテナやWebコンテナとは別の物理サーバーで実行する必要があります。データベースサーバーとコンピュートマシンの間の遅延は、数ミリ秒以内である必要があります。
許可リストは、ホスト名とIPアドレスのどちらでも作成できます。
詳しくは、ネットワーク要件のドキュメントのホスト名のセクションをご覧ください。
はい、TCP接続が必要です。ビジネスが追加のポートを開くことができない場合は、終了したSSLを使用できます。
詳しくは、ネットワーク要件のドキュメントをご覧ください。
いいえ、FacebookはKOPSをサポートしていません。ECSに基づくAWSソリューションはサポートしています。一般的なKubernetes minikubeのセットアップにも対応しています。
データの管理
MySQLとPostgreSQLがサポートされています。Dockerを自分で実行している場合、コンテナが接続するMySQLまたはPostgreSQLデータベースを用意する必要があります。AWSテンプレートを使用すると、デフォルトではMySQLデータベースが設定されます。
いいえ。現時点では、WhatsApp Business APIクライアントはDocker for Windowsでは動作しません。開発に必要な場合は、Linux仮想マシンを使用して、Linux上でDockerを実行する方法をおすすめします。本番ワークロードには、互換性とパフォーマンスの問題を回避するためにLinuxサーバーを使用することをおすすめします。
Dockerコンテナを再起動するには、次のコードを実行します。
コアアプリDockerコンテナ
docker restart wacore<Current_WABA_Version>
Webapp Dockerコンテナ
docker restart webapp<Current_WABA_Version>
どのバージョンを実行しているのか確認するには、次のコマンドを実行します。
docker ps
はい。webappコンテナのログローテーションとcoreappコンテナのログローテーションの動作には、若干の違いがあります。
- Webapp: 最新のログファイル30件が保持されます。ログファイルのサイズが20MBを超える場合にのみ、ローテーションが行われます。
- Coreapp: 最新のログファイル30件が保持されます。ログファイルのサイズが15MBを超える場合にのみ、ローテーションが行われます。ローテーションが行われたファイルは圧縮されます。
外部からトリガー可能な、コンテナ内の古いログをクリーンアップする次のスクリプトを使用できます。
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
このスクリプトは、Webappコンテナにもコアアプリコンテナにも使用できます。このスクリプトを実行すると、コンテナ内に30ファイルのみが残るように、古いログファイルが削除されます。
容量が少なくなると、システムの動作が遅くなることがあります。メディアファイルやメッセージが多すぎることや、ログファイルが大きすぎることが原因と考えられます。ログファイルは自動的にローテーションされますが、サイズが大きくなった場合は削除しても問題ありません。
メッセージはデータベースに保存されています。メッセージは必要に応じて削除することができます。また、アプリケーション設定でpass_throughがfalseに設定されていると、メッセージは明示的に削除されるまですべてデータベースに保存されます。
ユーザーから送信されるメディアファイルは、メディアボリュームにダウンロードされます。どのメディアファイルを削除するかはビジネスに委ねられていますが、通常はどのメディアファイルを削除しても問題ありません。docker inspect your-container-idを使用してメディアファイルの場所を確認できます。
はい、WhatsAppに関連するテーブルに手を付けずにデータベースを他の方法で使用することができます。
データベース表には、アプリの設定、チャットスレッド、メッセージ、メディアなどに関連する情報が保存されます。これらはすべて、アプリを動かすために必要な情報です。
v2.25.xでは、過去のリリースに比べてアウトバウンドおよびインバウンドのパフォーマンスが改善されています。この最適化は、追加のデータベース接続を作成することによるものです。デプロイメントによっては、これによりデータベース接続数が増加し、構成されている上限に達する場合があります。パフォーマンスの向上を維持するため、データベースサーバーが受け入れることができる接続の最大数を増やすことができます。それが不可能な場合は、axolotl_context_striping_disabledパラメーターを変更して、この動作を無効にすることができます。この変更を行う方法について詳しくは、アプリ設定のドキュメントを参照してください。
データベースガベージコレクションは、データベースを管理しやすくするために、messagesテーブルとmessages_reciept_logテーブルを定期的にクリーンアップします。
ガベージコレクターは、配信/処理が正常に動作するように、特定のメッセージを維持します。たとえば、特定の期間に受信したメッセージを維持して、ビジネス統合がメッセージを既読としてマーク付けできるようにします。
Coreappでは、ガベージコレクションがランダムな間隔(たとえば、数時間ごと)で実行されます。これは、データベースでの競合による高可用性スタックでのパフォーマンス低下の危険性を防止するためです。
ガベージコレクションはコールバックキューとは無関係に動作します。たとえば、Webhookサーバーが4日間使用できない場合は、Webhookサーバー接続の復旧時に配信されるようにコールバックが保存されます。
messageStore.messagesテーブルとmessageStore.messages_receipt_logテーブルからメッセージと対応するメッセージ受信を破棄するには、データベースガベージコレクションのservices APIエンドポイントを使用します。
登録
現在の設定をバックアップして新しいマシンでそれを復元する場合、登録情報は実装のその他の部分とともに移行されるはずです。詳細については、「バックアップと復元の設定」ドキュメントをご覧ください。
認証
usersエンドポイント経由でユーザーアカウントからログアウトすると、そのアカウントに割り当てられたすべての認証トークンが無効になります。ユーザーを削除しても同じ効果が得られますが、それはかなり極端なやり方です。usersエンドポイント経由でユーザーアカウントにログインすると新しい認証トークンが返されますが、そのユーザーに対してすでに利用されている認証トークンは無効にならないことに注意してください。以前プロビジョニングされたトークンを所有しているすべての人は、トークンが期限切れになるか前述の方法のいずれかで無効化されるまで、トークンを引き続き使用できます。
メッセージの送信
注:WhatsApp Business APIを使用して、同じ受信者に同じメッセージを繰り返し送信しないでください。
配信率が100%でない場合は、いくつかの理由が考えられます。よくあるケースとしては、ネットワークにたまにしかアクセスしないユーザーや、一定期間アクティブでないユーザーがいることや、高品質のユーザーエクスペリエンスを作成すること が挙げられます。
WhatsAppで配信可能なメッセージには、配信率が非常に高いという傾向があります。しかし、メッセージが配信されなくなり得る理由はたくさんあります。コールバックをモニタリングすることで、メッセージの正確なステータスを把握することができます。しかし、これは、例えば、SMSでメッセージを送信する場合とは異なります。この場合、最終送信ステータスにアクセスできなかったため、メッセージを再送信すると、まったく異なる結果になる可能性があります。
ユーザーの携帯電話が故障している、バッテリ切れである、または携帯電話を紛失したユーザーが新しい携帯電話を入手して以前のSIMを停止したなどの理由で、メッセージが配信されないままになっていることがあります。ビジネスクライアントがネットワークに接続しようとするときにエラーが発生する可能性があります。コールバック(Webhooks)が配信されない可能性もあります。healthノードを使えば、これらの状況をモニタリングすることができます。サーバーの受信コールバックをオンにして、メッセージがWhatsAppサーバークラウドに配信されたことを確認できます。
ユーザーがネットワークに再接続した場合は、送信したメッセージがすべてユーザーに送信されます。同じコンテンツのメッセージを何通も受信することは、ユーザーにとって気持ちのよいことではありません。ユーザーからブロックされたり、クレームを受けたりする確立が高まります。配信登録が解除されかねません。
送信したメッセージに対してAPIからメッセージIDを受け取ったなら、そのメッセージを送信するためにすべきことはすべて完了しています。同じコンテンツを同じ受信者に再送信しないでください。
長期にわたって配信率が低下している場合は、 ダイレクトサポートからサポートチケットを提出してください。
メッセージを送信するとメッセージIDが返されますが、それはメッセージリクエストがデータベースに格納されたことを意味します。WhatsAppビジネスAPIクライアントは、WhatsAppサーバーによって認識されるまで、そのメッセージの送信を試行し続けます。このプロセスに終了期限はありません。次に、WhatsAppサーバーは、メッセージをユーザーの携帯電話に配信しようとします。ユーザーの携帯電話がオンラインでない場合、メッセージは30日間保存された後、WhatsAppサーバーによって破棄されます。
現時点では、何人のユーザーが、またどのユーザーが、ビジネスをブロックしたかを知る方法はありません。最良の指標としては、ステータスコールバックをリッスンし、deliveredステータスを受け取らない場合、そのユーザーはビジネスをブロックしているか、ネットワーク接続がないかのいずれかであることがわかります。詳細については、Webhookに関するドキュメントをご覧ください。
ユーザーがビジネスをブロックしている場合でも、Contacts APIは引き続きその電話番号を有効なWhatsAppユーザーとして返します。しかし、メッセージを送信しても、配信されることはありません。それが有料メッセージの場合、料金は発生しません。
通常の消費者向けのシナリオでは、送信者がユーザーのアドレス帳に入っておらず、この相手に以前にメッセージを送信したことがない場合、これが正常な動作です。エンタープライズ向けのシナリオでは、ユーザーとの間に最初に「信頼」を確立するように依頼する際に、ビジネスはメッセージテンプレートを使用します。これを行うことで、WhatsApp Business APIクライアントはアプリ内の自動ダウンロード設定のとおりに動作します。
通常の消費者向けのシナリオでは、送信者がユーザーのアドレス帳に入っておらず、この相手に以前にメッセージを送信したことがない場合、これが正常な動作です。企業向けのシナリオでは、ユーザーと初めてやり取りする際に、事業者はメッセージテンプレートを使用して「信頼」を確立します。こうすれば、WhatsApp Business APIクライアントでリンクがレンダリングされ、クリックできるようになります。
もちろんです。WhatsAppの担当者に連絡し、リクエストしてください。
いいえ。メッセージが送信された順序で到着することは保証されていません。順序が重要な使用事例では、最初のメッセージの配信のコールバックをリッスンしてから、2つ目のメッセージを送信する方法を推奨します。
If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.
No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.
メディア
メディアボリュームのマウントポイントを見つけるには、dockerコマンドを実行します。
リクエスト
docker volume inspect whatsappMedia
応答
[
{
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
"Name": "whatsappMedia",
"Options": {},
"Scope": "local"
}
]次に、すべての着信メディアファイルを表示するには、上記で受け取ったMountpointファイルパスを指定してlsコマンドを実行します。
ls /var/lib/docker/volumes/whatsappMedia/_data/
AWSの設定では、メディアボリュームはホスト上の/mnt/wa/mediaパスにマウントされます。
最大ファイルアップロードサイズは64MBです。この制限はメッセージで送信される画像、ドキュメント、ビデオにも適用されます。
メディアの削除のタイミングは各ビジネス次第です。
メディアをアップロードするとメディアIDを受け取りますが、これを使用してアップロードしたメディア要素を含むメッセージを送信することができます。メディアメッセージを送信すると、WhatsApp Business APIがメディアを暗号化してから WhatsAppサーバーにアップロードし、メディアはそこに14日間保持されます。その後、各ビジネスはメディアIDを指定してメディアを削除するか、後の使用のために保持するかを判断できます。メディアを30日間保持することを推奨していますが、それぞれのビジネスポリシーや使用事例に応じてリテンションポリシーを決めてください。
画像には、説明としてキャプションが追加されます。AndroidとiPhoneのどちらの画像も、キャプションテキストは実際の長さで表示されます。
ドキュメントの場合、キャプションはファイル名に置き換わります。これは、ユーザーのデバイスに説明テキストとして表示されることを意図しておらず、代わりにファイルの名前を示しています。iPhoneの場合は実際のテキストの長さで表示されますが、Androidはファイル名が短縮されて表示されます。これは、両方のデバイス上のWhatsAppにおける現在の実装の技術的な制限です。
WhatsApp Business APIから画像をアルバムとして送信する際は、少なくとも4つの画像を連続して送信する必要があります。画像の受信時点でユーザーのスレッドビューがアクティブになっていると、次回のアクセスまでアルバムビューは利用できません。
次のいずれかの条件に該当する場合、アルバムは作成されません。
- キャプション付きの画像
- 未読の小見出し - 一部の画像のみユーザーに表示されます
- 日付ヘッダー - 配信の合間の新しい日付
いいえ。現在のところ、CoreappとWebappの間でメディアボリュームを共有するには、AWS EFSを使用する必要があります。
いいえ、現在のところ、メディアストレージのデフォルトパス(/usr/local/wamedia/)を変更することはできません。適切に動作させるには、すべてのメディアストレージをこのデフォルトの場所に配置する必要があります。
メッセージテンプレート
現在は7日間です。キャッシュに7日間以上更新がない場合、パックのエレメントの有無に関わらずサーバーから最新の言語パックが取得されます。
注:fallback言語ポリシーはv2.27.8以降廃止されており、現在ではdeterministic言語ポリシーがデフォルトポリシーです。
新しい言語で翻訳を作成する場合、使用するすべてのエレメントを新しい言語に翻訳する必要があります。そうしないと、受信者の携帯電話で自分の言語でのエレメントが見つからず、「structure unavailable」エラーが発生することがあります。このような「structure unavailable」エラーは、フォールバックポリシーを使用してテンプレートメッセージを送信する際に表示されます。
現時点で言語の翻訳を作成することができない場合、決定性ポリシーを使用してこれらのエラーを回避することができます。
Webhooks
WhatsApp Business APIクライアントからWebhookコールバックがCoreappコンテナを介して送信されます。そのため、Webhookエンドポイントは、Coreappからのインバウンドリクエストを受け入れるように構成されている必要があります。
Webhookがコールバックの送信に失敗すると、コールバックは再試行キューに入れられます。最初の失敗したコールバックより後に送信されたコールバックは受信されません。最初の失敗したコールバックが成功すると、後続のコールバックが続きます。
何らかの理由でWebhookイベントが配信されない場合(例、クライアントがオフライン)やWebhookリクエストが200以外のHTTPステータスコードを返す場合、webhookの配信が再試行されます。配信は、特定のタイムアウト(通常は24時間ですが、異なる場合もあります)まで、または配信が成功するまで、漸増する遅延により継続的に再試行されます。
重複したメッセージがWhatsApp Webhookに送信されるのは、メッセージが少なくとも1回(1回だけではなく)必ず受信されることを保証するためです。これが端末でのメッセージの処理方法に影響する場合は、メッセージIDに基づいて重複するWebhookメッセージが削除されるようにすることをおすすめします。
pass_throughアプリケーション設定を再確認してください。WhatsApp Business APIクライアントv2.29.1以上でpass_throughを有効にしている場合、読み取りステータスのコールバックを受け取れません。
読み取りステータスのコールバックを受け取りたい場合は、pass_throughアプリケーション設定を無効にしてください。pass_throughを無効にすると、データベースストレージが急激に増大することがあるので注意してください。データベースの管理の詳細については、データベース管理に関するドキュメントをご覧ください。
エラー
これは、古いバージョンのiOSクライアントの不具合が原因です。一般人口の増加に伴って、エラーが減少することが期待されます。
これは既知の問題です。CloudFormationスクリプトを使用してWhatsApp Business APIをアップグレードする場合、RDS DBスタックへの更新も必要になることがあります。新しいRDSスタックのホスト名が元のスタックのホスト名とは別のものになるため、Dockerコンテナがデータベースに接続できなくなります。解決策として、CloudFormationによって作成されたEC2インスタンスにSSHを使用して接続し、新しいホスト名を使用してwhatsapp.confファイルを更新してから、Dockerコンテナを再始動して新しい設定を適用します。
これは、Dockerブリッジが破損している場合に発生します。最適な改善方法は、Dockerサーバーを停止してから再始動することです。また、コンテナでdocker restartを試行する方法もあります。
「connection refused」エラーは、恐らくCoreappが実行されていないことを意味しています。docker psを使用して、Coreappが動作しているかどうかを確認してください。動作していない場合、Dockerのログを確認してください。Coreappはデータベースに接続できない可能性があります。データベースが正しく設定されていることを確認してください。
多くの原因が考えられます。Coreappがダウンしているか、データベースが正しく設定されていない可能性があります。それ以外の場合は、Coreappログ(マルチコネクトを実行している場合はマスターCoreappログ)をご覧ください。データベース接続エラーが表示される場合、接続を使い果たしていることが考えられます。このエラーに関しては、MySQLのドキュメントまたはPostgreSQLのドキュメントを参照してください。
データベースで接続数を増やすことをおすすめします。データベース接続数が1000個あれば安全と考えられますが、接続数については詳細を十分に検討したうえで決定してください。エラーが続く場合は、サポートチケットをオープンしてください。
このエラーが表示されていても、エラーで参照されている必須パラメーターがjson本体に設定されているのであれば、 json解析エラーである可能性があります。jsonフォーマットエラーが原因でjsonペイロード全体が解析不能である場合に、このエラーが発生することがあります。これらのパラメーターの値に、末尾の改行など、無効なjson文字がないかどうか確認してください。コピーしたパラメーターに余分な空白文字が含まれていて、その中にjsonを終了する文字があるということもよくあります。
スマートフォンがテンプレートメッセージを読み取れない場合、structure unavailable (構造利用不可)のエラーが発生します。
テンプレートはサーバーに保存されています。テンプレートメッセージが messages ノードを使って送信されると、メッセージ全体ではなく、名前空間、言語、要素名、ローカライズされたパラメーターのみがスマートフォンに送信されます。これらの値がスマートフォンに配信されると、スマートフォンはメッセージのレンダリングを試みます。
レンダリングの間に何らかのエラーが発生した場合、 structure unavailable エラーが、受信者とメッセージIDが指定されてコールバックURLに送信されます。このようなエラーは、ネームスペースが間違っている、ローカライズされたパラメーターが一致しない、要素名が間違っているなどの理由で発生します。
FacebookビジネスマネージャのWhatsAppマネージャに移動し、パラメーターの正しい数を確認してください。ネームスペースが正しく、要素名が存在していることを再度確認してください。
エラーのよくある原因の1つは、使用しているすべてのテンプレートの翻訳を作成していないことです。たとえば、よく送信する2つのテンプレートがあり、そのうちの1つの新しい言語の翻訳を追加する場合、もう一方のテンプレートのその言語の翻訳も必ず追加してください。複数の言語をサポートする予定の場合、サポートするすべての言語の翻訳を、すべてのテンプレートに対して用意する必要があります。
幸いなことに、 structure unavailable エラーの通常の原因は messages API呼び出しに誤りがあることであり、その場合は送信ペイロードを変更することで修正できます。
メッセージを送信する前に、まず連絡先が存在するかどうかを確認する必要があります。この方法について詳しくは、連絡先に関するドキュメントを参照してください。
WhatsApp Business API Clientのすべてのビルドには、リリース日から6か月の有効期限があります。このエラーが表示された場合は、できるだけ早く最新のリリースバージョンにアップグレードしてください。
WhatsAppは、WhatsApp Business API通知がユーザーエクスペリエンスおよび一般的な製品全体に及ぼす影響を測定および理解するための実験を実行します。メッセージ送信先のユーザーがこれらいずれかの実験の対象者である場合、それらのユーザーは、メッセージの受信をオプトインしていたとしても、通知を受け取らないことがあります。
AWSデプロイメントの設定時に次のようなエラーが表示される場合は、8文字以下のスタック名に変更してみてください。
国名(2文字のコード) [AU]:州名(正式名称) [州]:市区町村名(市など) []:組織名(会社など) [Internet Widgits Pty Ltd]:組織単位名(部署など) []:共通名(サーバーFQDNや個人名など) []:文字列が長すぎます。64バイト未満の共通名(サーバーFQDNや個人名など)を使用する必要があります。[]:メールアドレス []:エラー。構成ファイルにオブジェクトが指定されていないため、internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.comの証明書リクエスト作成デバイスキーに問題が発生しました。
ビジネスプロフィールのデータが一部のみ設定されている場合は、空のprofileオブジェクトが返されます。この問題を解決するには、v2.21.4にアップグレードしてください。
ビジネスプロフィールの設定を完了する方法について詳しくは、ビジネスプロフィール設定ドキュメントを参照してください。
471エラーコードは、品質ベースのレート制限と関連があります。詳細については、品質ベースのレート制限に関するドキュメントをご覧ください。
メッセージテンプレートの送信側検証エラーと、エラーが表示される原因を以下に示します。
- 「言語your-languageにメッセージテンプレートが存在しません」または「言語your-languageおよびロケールyour-localeにメッセージテンプレートが存在しません」 — 指定された言語パックが存在しません。ビジネスマネージャアカウントを確認してください。
- 「テンプレートyour-template-nameが言語your-languageに存在しません」または「テンプレートyour-template-nameが言語your-languageおよびロケールyour-localeに存在しません」 — 使用しようとしているテンプレートが存在しません(作成されていないか、まだ承認されていません)。削除されたテンプレートを使用してメッセージを送信しようとしたときも、このエラーが表示されます。
- 「localizable_paramsの数num1が、期待されるparamsの数num2と一致しません」 — 送信しようとしているメッセージテンプレートのパラメーターが、期待されるパラメーターの数と一致しません。API呼び出しが正しいことを確認してください。
- 「your-template-nameはリッチテンプレートであり、テンプレートメッセージAPIを使用する必要があります」 — メディアメッセージテンプレートを通常メッセージテンプレートとして送信しようとしています。メッセージタイプが
templateであることを確認してください。詳しくは、「メッセージテンプレートに関するドキュメント」をご覧ください。 - テンプレートがビジネスマネージャで承認(または削除)されてから、WhatsApp Business APIクライアントが更新されたテンプレートを受信するまでに最大で20分かかります。承認されたばかりのテンプレートを使用してメッセージを送信しようとしたときに、テンプレートが存在しないというエラーが表示された場合は、上記の時間が経過するのを待ってからメッセージの送信を再試行してください。
v2.29.xまでは、バグのために、時間経過とともに送信メッセージキューのサイズが大きくなることがありました。v2.29.3にアップグレードすればこの問題は解決します。
Coreappによって、Coreappコンテナ内の/usr/local/waent/dataディレクトリと/usr/local/waent/logディレクトリに10MB以上のストレージがあることがチェックされ、不足している場合はこの重大なエラーが発生します。
ログやデータディレクトリをチェックして、十分な空き容量を確保してください。
その他
現在、そのような方法はありません。WhatsAppからのユーザーの着信に応答できる状況ではない場合、正規のサポートチャネルへの連絡先を案内する自動応答メッセージを送信するように設定することをおすすめします。
テスト用には、2つ目の電話番号を登録して、2つ目のCloudFormationスタックまたはDockerインスタンスを作成してください。同じ電話番号を使用するアクティブなWhatsApp Business APIクライアントが2つあると、暗号キーが競合することにより、サーバーから追い出される可能性があります。2つ目の環境を作成し、それを使用して本番ではないインスタンスをテストしてから、本番用クライアントに移行する、という方法をおすすめします。
カスタマーがWhatsAppの電話番号を変更しても、ビジネスには通知されません。contactsノードを使用すると、その電話番号のステータスはinvalidとなります。
電話番号が使用不可になったカスタマーが、引き続きWhatsAppを利用している場合、電話番号を再割り当てまたは再登録するまで、カスタマーは引き続きWhatsAppにアクセスできます。
WhatsAppでは、入力された電話番号が実際にその携帯電話のものかどうかを厳密に検証します。ユーザーがWhatsAppアカウントを持っているということは、そのユーザーの電話番号で認証済みで、それ以降に別のユーザーがその電話番号でWhatsAppに登録していないことを証明するものです。しかしそれは、SIMカードの物理的な所在を保証するものではありません。
一方、ユーザーが携帯電話を紛失した、または盗難にあった場合は、WhatsAppアカウントを利用解除することができます。アカウントを利用解除する方法について詳しくは、携帯電話を紛失した、または盗難された場合に関するよくある質問をお読みください。
いいえ。同じ電話番号を使用している複数のデバイスをWhatsAppビジネスAPIを使って検出する方法はありません。
ユーザーから送信されるメッセージペイロードは、テキストまたはメディアファイルのいずれかです。
テキストの場合、これまで危険は確認されていないと考えられています。
メディアファイルの場合:
- 一般的に、ビジネスは、潜在的な脅威を分析するための適切な保護ソフトウェア（ウイルス対策やマルウェア対策用のソフトウェア）を備えていることが期待されます。
- 転送されるファイルはエンドツーエンドで暗号化されているため、WhatsAppはそのようなファイルのコンテンツを識別または確認できません(テキストのみのコンテンツについても同じです)。
- ただし、WhatsAppビジネスAPIクライアントにメディアファイルが自動的にダウンロードされないようにする方法があります。ビジネスがユーザーからのファイルを受け取らないようにするには、
auto_downloadフィールドを空の配列に設定します。
リリースv2.18.26以降、アプリケーションの統計情報エンドポイントでは、内部指標をPrometheusテキスト形式でエクスポートすることが可能です。詳細については、インスタンスのモニタリングに関するドキュメントをご覧ください。
WhatsApp BusinessオンプレミスAPIクライアントの場合、ビジネスとカスタマー間で送信されたメッセージを復号するためのキーを保管するデータベースが必要になります。WhatsAppのすべてのメッセージは、送信者と受信者のキーで暗号化されています。カスタマーのキーはカスタマーのモバイルデバイスに保存され、ビジネスのキーはそのビジネスのデータベースに保存されます。詳しくは、WhatsAppのセキュリティをご覧ください。
Metaがビジネスのデータベースをホストしてる場合、WhatsApp BusinessクラウドAPIを代替として使用できます。クラウドAPIを使用すれば、自社サーバーをホストする経費をかけずにWhatsApp Business APIを実装できます。詳しくはこちら。