ベータ版。 Automations API はベータ版であり、現在フィードバックを積極的に収集しています。改善を重ねる中で、エンドポイント、ペイロード、および制限が変更される可能性があります。改善の優先順位付けのため、フィードバックとバグレポートをサポートまでお送りください。
仕組み
1
オートメーションを作成する
使用したいトリガーとアクションを指定して
POST /automations を実行します。オートメーションは即座に有効化されます。2
エンドユーザーがエンゲージメントを行う
誰かがあなたの投稿にコメントする、ストーリーに返信する、DM を送信する、または DM にリアクションします。Meta が Webhook を Ayrshare に配信します。
3
Ayrshare がマッチしてディスパッチする
エンジンはイベントにマッチするすべてのルールを検索し、アクションごとの重複排除と 1 日あたりの DM 上限をチェックし、各アクションを実行します。DM 送信には Instagram のスパム対策ヒューリスティクスの範囲内に収まるよう 20〜60 秒のジッターが適用されます。
4
発火した内容を確認する
GET /automations/:id/activity で監査ログ — すべてのディスパッチ試行、アクションごとの結果、および発生したエラー — が返されます。Triggers
1 つのオートメーションに最大 50 個の triggers を紐付けできます。各トリガーはtype フィールドを判別子とする union で、タイプ固有のフィールドは同じレベルに配置されます。v1 ではすべての triggers は Instagram のみに対応しています。
キーワードマッチングは大文字小文字を区別しない、単語単位でのマッチです。イベントは、設定されたキーワードのいずれか 1 つを含んでいれば、キーワードフィルタ付きトリガーを満たします。ストーリートリガーで
storyId を省略すると、連携された全アカウントのすべてのストーリーで発火します。
Actions
1 つのオートメーションに最大 50 個の actions を紐付けできます。これらは順次実行され、各結果はアクティビティ行に記録されます。アクションごとの重複排除ウィンドウ
すべての action は、その action のみに対して 既定の 7 日間 の受信者ごと重複排除ウィンドウを上書きする、オプションのトップレベルdedupWindowMinutes フィールドをタイプに関係なく受け入れます。
- そのアクションで重複排除を完全に無効化するには
0を設定します(受信者がすべてのイベントを期待するfire_webhook/send_emailで一般的)。 - 上限は
525600(1 年)です。
Action with a 24h dedup override
fire_webhook payload
fire_webhook が実行されると、以下の JSON ボディがアカウントレベルの Webhook URL に POST されます。
dm_keyword は Meta のペイロードにユーザー名を含まない、story_reply にはキーワードがない)、recipientUsername と keyword は null になります。
テンプレート変数
send_dm.message、send_email.subject、および send_email.message は {{placeholder}} の置換をサポートします。不明なプレースホルダーは作成/更新時に拒否されます(473 バリデーションエラーとして)。これにより、タイプミスがそのまま {{foo}} としてお客様向けメッセージに紛れ込むことを防ぎます。
sender_email / recipient_email はありません。 これらは意図的に公開されていません — 請求用メールアドレスが見知らぬ相手への DM に含まれる正当な理由はなく、Meta も IG の Webhook で受信者のメールアドレスを提供しません。これらのプレースホルダーを避けることで、意図しない情報開示を防ぎます。レート制限と上限
アクティブなオートメーションの上限は、親アカウント単位ではなく、User Profile ごとにカウントされます。アカウント配下の各プロファイルはそれぞれ Business 10 / Enterprise 50 の枠を持つため、多数のプロファイルを持つアカウントでは各プロファイルでその数のオートメーションを実行できます。この上限はアクティブなオートメーションをカウントし、
POST(作成)および PUT による再有効化(active: false → true)の双方で適用され、それぞれエラーコード 470 を返します。プロファイルごとの上限引き上げが必要ですか? サポートまでお問い合わせいただくことで、アカウントに対して上限を引き上げることができます。
1 日あたりの DM 上限 は Ayrshare の親アカウントごとに適用され、すべてのプロファイル間で共有されますが、プロファイルごとのサブ上限があるため、忙しい 1 プロファイルがアカウント全体のクォータを使い切ることはありません。DM 上限に達すると、アクティビティ行に rate_limited ステータスが記録され、DM は送信されません。
1 つのオートメーションに対する構造的上限: triggers 1〜50 個、actions 1〜50 個。
Instagram 自体はアカウントあたり約 200 件/時の DM 上限を課しています。エンジンは 20〜60 秒のジッターでディスパッチをペーシングし、この上限を安全に下回るようにします。
アクティビティのステータス
GET /automations/:id/activity の行には、トップレベルの status と actionResults[] 内のアクションごとの status が含まれます。
pending と in_flight は一時的な状態で、それ以外はすべて終端状態です。
エラーコード
API は 2 種類のエラー形式を返します。- ビジネスルールエラー はオートメーション固有の番号付き
codeを持ちます(例:{ "action": "automation", "code": 469, ... })。 - バリデーションエラー — 不正なリクエストボディ全般(必須/無効なフィールド、不明なテンプレート変数、認識されないキー)は、単一の
473レスポンスとして返され、detailsオブジェクトに問題のあるフィールドが列挙されます。detailsはバリデータの出力(formErrorsとfieldErrors)です。条件ごとのコードではなく、detailsで分岐してください。fieldErrorsでは、キーはトップレベルのリクエストフィールド(triggers、actions)です。特定のエントリ内の問題(例: トリガーでkeywordsが欠落)は、そのフィールド(例:triggers)配下で報告されます。一方、formErrorsにはオブジェクトレベルの問題(認識されないキーなど)が含まれます。
Meta が許可していないこと
一般的にリクエストされる機能のうち、Meta が公開 Instagram API で許可していないため、以下はサポートされていません。- 新規フォロワーへの自動 DM。 Instagram はフォロー Webhook を公開していません。
- 見知らぬ相手への初回 DM。 Meta はビジネスアカウントがメッセージを送信する前に、受信者側からのコンタクト開始(コメント、返信、DM、リアクション)を必須としています — これは本機能でサポートしているすべての trigger が満たす条件です。
- 一斉アウトバウンドキャンペーン。 プラットフォームレベルで 1 時間あたりの DM 上限とスパム対策ヒューリスティクスが適用されます。
マルチプロファイル利用
エンドポイントはprofileKey ヘッダーを尊重します。子プロファイルのキーを渡すと、そのプロファイル配下でオートメーションが作成/管理されます。プロファイルごとのサブ上限によってレート制限がプロファイル間で分割されるため、おしゃべりな 1 プロファイルが親アカウントのクォータを使い切ることはありません。
FAQ
新規フォロワーをトリガーにできますか?
新規フォロワーをトリガーにできますか?
いいえ。Instagram はフォロー Webhook を公開しておらず、Meta はサードパーティアプリが会話を開始していないユーザーに DM を送信することを許可していません。サポートされるすべてのトリガー(
comment_keyword、story_reply、dm_reaction、dm_keyword)は「ユーザーが最初にコンタクトした」という要件を満たしています。オートメーション発火時にアクセストークンが無効だった場合はどうなりますか?
オートメーション発火時にアクセストークンが無効だった場合はどうなりますか?
アクティビティ行に
auth_error ステータスが記録され、DM は再試行されません。アカウントを再連携すれば、次にマッチしたエンゲージメントで通常通り発火します。DM 送信前に遅延があるのはなぜですか?
DM 送信前に遅延があるのはなぜですか?
各
send_dm のディスパッチは、Instagram のスパム対策システムから見て自然に見えるよう、エンゲージメントの 20〜60 秒後にスケジュールされます。fire_webhook および send_email アクションにはジッターはありません。アクティビティ行の created タイムスタンプはトリガーがマッチした時刻、completedAt はディスパッチが完了した時刻です。アクティビティ行は永久に保持されますか?
アクティビティ行は永久に保持されますか?
アクティビティ行はトレースと分析のため無期限に保持されます。
GET /automations/:id/activity エンドポイントはパフォーマンス上の理由から直近 30 日間の行を返します。(重複排除ガードは独自のアクションごとのウィンドウ — 既定 7 日間 — を使用し、これはアクティビティのルックバックとは無関係です。)オートメーションを削除するとアクティビティ履歴も削除されますか?
オートメーションを削除するとアクティビティ履歴も削除されますか?
いいえ。削除はソフト削除です。マスター行に
deleted フラグが立ち、新規のディスパッチは発生しなくなりますが、履歴のアクティビティ行はアクティビティエンドポイントから引き続き読み取れます。エンドポイント
POST /automations— 新しいオートメーションを作成するGET /automations— オートメーションを一覧表示するGET /automations/:id— トリガーとアクションを含むオートメーションを 1 件取得するPUT /automations/:id— 部分更新。active: falseで一時停止するDELETE /automations/:id— ソフト削除GET /automations/:id/activity— カーソルページネーション付きのディスパッチ監査ログ
