Skip to main content
Webhook には複数のタイプがあり、アクションタイプごとに分類されています。 たとえば、スケジュール投稿は scheduled アクション Webhook をトリガーします。 詳細については Webhook 概要 を参照してください。 Webhook URL を登録した後、イベントが発生すると URL に対して POST リクエストを受信します。 POST リクエストにはイベントの詳細を含む JSON ペイロードが含まれます。

Scheduled アクション

スケジュール投稿が処理されるとき(成功したか失敗したかを問わず)、選択したソーシャルネットワークに公開された際にこの Webhook 通知を受信します。 たとえば、2026 年 8 月 1 日午後 12:00 に投稿をスケジュールした場合、投稿が公開される正確な時刻に Webhook が送信されます。 Webhook 通知は、/post エンドポイントの scheduleDate フィールドを使用して将来にスケジュールされた投稿に対してのみ送信されます。

Scheduled イベント

即時投稿の場合、API は JSON 応答で即座に成功または失敗のレスポンスを返すため、Webhook 通知は受信しません。 Webhook 通知は、非同期で処理され、ステータスを通知するために別の通知を必要とするため、スケジュール投稿に対してのみ送信されます。

TikTok 公開 Webhook

Ayrshare を通じて TikTok を使用する場合、スケジュール投稿に対して 2 つの異なる Webhook を受信することがあります。 投稿が即時ではなくスケジュールされていた場合、まず標準の Scheduled Action Webhook を受信します。 これは、メディアが処理と投稿のために TikTok に正常に送信されたことを示します。 その後、subAction: tikTokPublished Webhook を受信します。 これは、TikTok がメディアの処理を完了し、メディアが公開されるとトリガーされます。 この Webhook は、即時投稿とスケジュール投稿の両方で有効化されます。 Ayrshare ダッシュボードでは、このイベントは tikTok (pub) としてラベル付けされます。
tikTokPublished Webhook は、メディアが公開される まで送信されません。 メディアが private、followers、または friends に設定されている場合、Webhook は送信されません。tikTokPublished Webhook を受信せず、投稿ステータスが pending のままの場合、メディアが TikTok によって受け付けられていることを確認するために TikTok モバイルアプリを確認してください。

Social アクション

ユーザーのプロファイルがソーシャルネットワークをリンクまたはアンリンクした際の通知。

Social アクションイベント

account オブジェクトは、リンクされたプラットフォームについて Ayrshare がアカウントレベルの識別情報を保持している場合(現在は YouTube のみ)に送信され、link と unlink の両方のアクションに含まれます。account 内のキーはすべて任意です(カスタム URL のない YouTube チャンネルには handle がありません)。識別情報がない場合、account キーは空で送信されるのではなく完全に省略されるため、使用する前にキーが存在するかを確認してください。 account.title はソーシャルアカウント自体のタイトル(YouTube のチャンネル名など)であり、トップレベルの title は Ayrshare のユーザープロフィールのタイトルである点に注意してください。これらは異なる値です。 source が system の場合、Ayrshare がソーシャルネットワーク接続がもはや有効でないなどの理由で自動的にアカウントのリンクを解除したことを意味します。ユーザーが投稿を続けられるように通知することをお勧めします。リンク解除の詳細は details フィールドにあります。プライマリアカウントのメールアドレス、または 代替メール が設定されている場合はそこにもメールが送信されます。 source が user の場合、ユーザーが自分でアカウントを手動でリンク解除するなど、ユーザー自身がアクションを開始したことを意味します。ユーザーが開始したアクションが発生した場合、メールは送信されません。

Messages アクション

すべての messages エンドポイントおよび webhook にアクセスするには、Messaging アドオンが必要です。 Facebook と Instagram では、新しいダイレクトメッセージが到着したとき、既読になったとき、またはメッセージに対してリアクションが作成または削除されたときに通知を受け取ります。WhatsApp は現在、新しい受信メッセージが保存されたときにのみ、登録された webhook URL に通知を送信します。 X/Twitter Webhook は、Enterprise クライアント向けのオプションとして利用可能です。 Enterprise クライアントになる方法の詳細については、アカウント担当者にお問い合わせください。 WhatsApp は現在、リアクションや配信ステータスの webhook を登録された URL に送信しません。保存されたアウトバウンドメッセージには、sent、delivered、read、または failed の status 値が付与される可能性があります — 下記の WhatsApp メッセージステータス を参照してください。

複数のアプリを持つ Facebook ページのスタンバイカバレッジ

Ayrshare は、標準のメッセージングフィールドに加えて、Facebook の standby webhook フィールドをサブスクライブしています。これは、同じ Facebook ページ上の別のアプリが現在スレッド制御を保持している場合(たとえばチャットボットプラットフォームがページのプライマリレシーバーとして設定されている場合、または Meta の Page Inbox がアクティブに会話を処理している場合)でも、Messenger イベントが webhook に配信されることを意味します。 これらのイベントにはスキーマの変更はありません。以下のセクションに文書化されている同じ messageCreated / messageRead / reactionCreated / messageEdited ペイロードとして到着します。競合する Messenger アプリがインストールされているページに関して注意すべき点が 2 つあります:
  • インバウンドメッセージ量が増加する場合があります。以前の動作では、サブスクライブされる前に standby イベントは静かにドロップされていました。新しいトラフィックは、他のアプリによって処理されていたページが受信したメッセージを表します。
  • Ayrshare を通じて送信していないメッセージに対応する type: "sent" の messageCreated イベントを受信する場合があります。これらは、ページ上の他の Messenger アプリによって送信されたメッセージのエコーです(Meta はすべての送信のコピーをサブスクライブされているすべてのアプリに配信します)。統合が独自の送信履歴とアウトバウンドトラフィックを照合する場合、その履歴を使用して自分の送信と競合アプリの送信を区別できます。
Ayrshare のみがインストールされているページ(競合する Messenger アプリなし)では、観察可能な唯一の変更は新しい Message Edit Event です — それ以外はすべて以前の動作と同じに見えます。

新規メッセージイベント

新しいメッセージが送信または受信されたときの通知。
ソーシャルネットワークに到達できない場合、一部のフィールドは省略されることがあります。conversationId と senderDetails は、メッセージが到着した時点でソーシャルネットワークから解決されます。この照会に失敗した場合、メッセージを差し止めるのではなく、解決できた情報のみでメッセージを配信し、connectionDegraded: true を設定します。通常の原因は、プロファイルの Instagram または Facebook の接続が期限切れになったか無効化されたことですが、一時的な Graph API エラーを含め、この照会のあらゆる失敗がこのフラグを設定します。両者は継続するかどうかで区別できます: 単一のメッセージのみであれば一時的なものであり対応は不要ですが、プロファイルからのすべてのメッセージで設定される場合は認証情報が失効しており、再リンクのみが解消手段です。
これが継続する場合は、そのプロファイルのソーシャルアカウントを再リンクすべきシグナルとして扱ってください。認証情報が失効していると、API を通じた返信や会話履歴の取得もブロックされます。どちらも同じ認証情報を必要とするためです。その間もメッセージは届き続けるため、受信データが失われることはありません。Facebook ページ経由で接続された Instagram アカウントは、そのページの認証情報に依存しているため、まず Facebook を、その後 Instagram を 再リンクしてください — Instagram だけを再リンクしてもフラグは解消されません。どのメッセージでも conversationId と senderDetails が存在しない可能性を許容できるように統合を構築してください。id、senderId、recipientId、platform は常に含まれます。なお、message も接続の健全性とは無関係に保証されません: 添付のみのメッセージは、message フィールドなしで attachments を持ちます。
WhatsApp の場合、conversationId と senderId は E.164 の数字のみの形式による相手の電話番号です。recipientId は、リンクされた WhatsApp アカウントの Meta の電話番号 ID です。timeStamp は Webhook Security が有効な場合に含まれます。 すべてのネットワークにおいて、メディアを含むメッセージは、上記の WhatsApp の例で示したように attachments でメディアを運びます — Facebook と Instagram も含まれます。添付のタイプは image、video、audio、document、または sticker になります。メッセージの webhook が mediaUrls を運ぶことはありません — このフィールドは Scheduled アクション などの投稿配信後のペイロードに属するものであり、そこでは送信したメディアを報告します。

メッセージ既読イベント

受信者がメッセージを読んだときの通知。
Instagram でメッセージが読まれたとき、webhook ペイロードには読まれた特定のメッセージを一意に識別する mid フィールドが含まれます。 Facebook メッセージでは、メッセージの既読は conversationId を使用して会話レベルで追跡されます。 既読イベントが発生した場合、created(または read)タイムスタンプより前のタイムスタンプを持つその会話内のすべてのメッセージは、ユーザーによって読まれたとみなされます。

リアクション作成および削除イベント

いいねなどのリアクションがメッセージに作成または削除されたときの通知。

メッセージ編集イベント

ユーザーが以前に送信したメッセージを編集したときの通知。Facebook と Instagram のダイレクトメッセージで利用可能です。 messageEdit.mid フィールドは元の messageCreated イベントの id と一致するため、消費者は編集を元のメッセージと関連付けることができます。messageEdit.text フィールドには、新しい編集済みのメッセージテキストが含まれます。

WhatsApp メッセージステータス

WhatsApp は、保存されたアウトバウンドメッセージについて、1 つの status フィールド(sent、delivered、read、または failed)を使用してメッセージごとの配信状態を追跡します。これらの更新は、現在別のイベントとして 登録された webhook URL に配信されません。リアルタイムの配信状態が必要な場合は、Ayrshare アカウント担当者にお問い合わせください。

Batch アクション

バッチの処理が完了してファイルが利用可能になったときの通知(すべてのユーザープロファイルの取得 など)。url フィールドの事前署名済み URL でファイルにアクセスできます。

Batch イベント

Feed アクション

登録された RSS フィードで新しい RSS フィードアイテムが見つかったときの通知。注意: Webhook がアクティブな場合、新しい RSS アイテムはソーシャルネットワークに自動的に投稿されません。

Feed イベント

Mentions アクション

接続されたアカウントがメンションされたときの通知。Instagram で利用可能です。
Instagram の場合、mentions webhook を登録するだけでメンションイベントを受信できます。Messaging アドオン、メッセージングの有効化、ソーシャルアカウントの再連携は不要です。
Ayrshare は Meta のネイティブメンションペイロードをそのまま中継し、標準のエンベロープフィールド(action, refId, hookId, url, Webhook Security 付きの timeStamp)、subAction、platform、postId のみを追加します。以下の例は Instagram の形式です: media_id、メンションがコメント内にある場合は comment_id。Facebook ページのメンションイベントは現在配信されません — Ayrshare は Meta からの受信を確認しますが、お客様の webhook には転送しません。現在配信されるのは Instagram のメンションのみのため、この action の platform は常に instagram になります。 postId は Comments アクション と同じルールに従いますが、メンションでは通常存在しません: メンションは通常、他のユーザーの投稿上で発生し、その投稿には Ayrshare の id がないためです。このフィールドが含まれるのは、Ayrshare を通じて公開した投稿上でメンションされた場合のみです。

メンションイベント (Instagram)

Comments アクション

接続されたコンテンツにコメントが作成されたときの通知。Facebook と Instagram で利用可能です。
Instagram の場合、comments webhook を登録するだけでコメントイベントを受信できます。Messaging アドオン、メッセージングの有効化、ソーシャルアカウントの再連携は不要です。Facebook の場合、コメントイベントはプロフィールでメッセージングが有効(Messaging アドオン)の間のみ配信されます。comments webhook の登録だけでは不十分です。Facebook ページの再連携は不要です。
Ayrshare は Meta のネイティブコメントペイロードをそのまま中継し、標準のエンベロープフィールド(action, refId, hookId, url, Webhook Security 付きの timeStamp)、subAction、platform、postId のみを追加します。以下の例は Instagram の形式です。Facebook コメントは、異なるフィールド名(たとえば comment_id, post_id, message, from.name など)を持つ Page feed change として到着します。Facebook のフィールドセットについては、Meta の webhooks リファレンスを参照してください。両ネットワークとも同じ comments エンドポイントに配信されるため、存在するフィールド名からネットワークを推測するのではなく、platform(instagram または facebook)で分岐してください。

コメントと自分が作成した投稿の関連付け

postId は、コメントが付いた投稿の Ayrshare の id です — 投稿作成時に Post が返した id と同じもので、Get Post や Post Analytics が受け付ける id でもあります。ネイティブ id の対応表を自分で保持しなくても、コメントを自分の投稿と照合できるようにするためのフィールドです。 これはベストエフォートであり、特定できない場合は省略されます。postId が存在しない場合は、エラーとしてではなく、「このコメントは自分が公開した投稿に対するものではない」と解釈してください。以下の場合には含まれません:
  • 投稿が Ayrshare を通じて公開されていない場合。 コメントイベントは、Instagram や Facebook のアプリで直接作成された投稿を含め、接続されたアカウント上のすべてのコンテンツに対して発火します。それらの投稿には Ayrshare の id がそもそも存在しないため、復元のしようがありません。
  • このフィールドの提供開始前に投稿が公開された場合。 関連付けデータは公開時に記録され、遡って補完されることはないため、それ以前の投稿へのコメントには postId は付与されません。
  • 投稿が別の User Profile によって公開された場合。 複数のプロファイルを同じ Facebook ページまたは Instagram アカウントに接続でき、すべてがコメントイベントを受信しますが、投稿の id が通知されるのは、実際にその投稿を公開したプロファイルのみです。
postId は Ayrshare の投稿 id であり、ソーシャルネットワーク側の id ではありません。同じ投稿に対するネットワーク自身の id は従来どおりの場所にあります — Instagram では media.id、Facebook では post_id です。

コメントイベント (Instagram)

Automations アクション

コメントや DM 自動返信トリガーなど、自動化がユーザーに対して webhook アクションを発火させたときの通知。 automations アクションでは 2 つのイベントタイプが送信され、type フィールドで区別されます。フィールドの完全なリファレンスについては webhook イベント を参照してください。

Automation Triggered イベント

Automation Completed イベント

Demo アクション

Demo User Profile のライフサイクルイベントに関する通知。Demo User Profiles は Enterprise plan で利用可能です。詳細については お問い合わせ ください。 demo アクションでは 2 種類のイベントタイプが送信され、type フィールドで区別されます。
  • upgradeWarning — Demo User Profile が自動的に標準の User Profile に変換される 2 日前に送信されます。これにより、ユーザーに継続を促す、あるいはプロファイルを削除することができます。
  • upgrade — 変換が発生したときに送信されます。

Demo Upgrade Warning イベント

Demo Upgrade イベント

Suspended アクション

User Profile が 停止または再有効化 された際の通知。停止は、ソーシャルネットワーク自身の措置(たとえば Facebook のアイデンティティ検証の要求)、レート制限保護、または請求上の問題によって発生する可能性があります。プロファイルが停止されている間、そのプロファイルに対する API 呼び出しは HTTP 403 を返します。 suspended アクションでは 2 種類のイベントタイプが送信され、type フィールドで区別されます。
  • suspend — プロファイルが停止されたときに送信されます。再有効化されるまで、このプロファイルの投稿およびその他のアクティビティを停止してください。
  • unsuspend — プロファイルが再有効化されたときに送信されます。
イベントは、プロファイル全体の停止状態が変化したときにのみ送信されます。プロファイルは同時に複数の原因で停止される場合があります: 既に停止中のプロファイルに追加の原因が加わった場合、または複数の原因のうち 1 つが解消されても別の原因が残っている場合、イベントは送信されません — プロファイルは停止されたままとなり、次のイベントは最後の原因が解消されたときの unsuspend になります。任意の時点で現在の停止状態を確認するには、Get Profiles を include=suspension と併せて使用してください。 プラットフォーム起因の停止は、通常、対象ネットワークに対する Social アクション の unlink イベントに続いて発生します。停止は発生源でのみ解決可能です — たとえば Facebook のアイデンティティチェックは Facebook アプリ内で Page 管理者が完了させる必要があります — その後、プロファイルを再有効化し、ネットワークを再リンクできます。

Suspend イベント

Unsuspend イベント

停止イベントは、状態が変化したプロファイルに対して送信されます。任意のタイミングで停止状態を確認したい場合は、Get Profiles を include=suspension と併せて使用することもできます。isSuspended、reason、suspendedAt、unsuspendAt、suspensionCount が返されます。