V4 Webhook
Webhook とは
Webhook は、(新しいファイルでトランスコードが完了したとき、コメントが追加されたとき、プロジェクトが作成されたときなど)アカウントで何か興味深いことが発生するとすぐに Frame.io が起動する、プッシュスタイルの HTTP コールバックです。 API をポーリングする代わりに、パブリック HTTPS URL を指定します。Frame.io は、その URL に JSON ペイロードをリアルタイムで送信するので、次のことができます。
Webhook の詳細と機能について詳しくは、https://docs.webhook.site/ を参照してください。
エンドポイントの概要
認証 — すべての V4 エンドポイントには、Adobe Developer Console を通じて取得された OAuth 2.0 アクセストークンが必要です。従来の開発者トークンおよび JWT は受け付けられません。
Frame V4 の変更と更新
レガシーで作成された webhook は、次の変更で V4 に転送されます。
- ペイロード構造:アカウント ID をペイロードに追加しました
- エンドポイントの変更:
team_idは、JSON ペイロードでは提供されなくなりましたが、代わりに 次の URL のパスパラメーターにあります:https://api.frame.io/v4/accounts/:account_id/workspaces/:workspace_id/webhooks - API 統合:API 構造、エンドポイント、および認証方法の変更により、リソースの強化および検索のために Frame.io API への後続の呼び出しを行う、受信 webhook の既存のコードは、更新が必要です
- イベントタイプ:アセット webhook は、個別のファイルおよびフォルダーイベントに分割されました。アセットイベントを含むレガシーからの webhook は、適切なファイルおよびフォルダーイベントを持つように更新する必要があります
移行後の webhook ステータス — アカウントが Frame.io V4 に移行されると、以前のバージョンの既存の webhook は自動的に無効になります。これにより、再アクティベートする前に webhook エンドポイントおよび統合ロジックを変更して、V4 のアップデートで作業できるようになります。V4 の互換性を得るように更新されていない webhook は、適切な変更をせずに有効にされた場合、エラーが発生します。どの webhook が非アクティブかを確認するには、API を通じて is_active フィールドを確認するか、webhook 設定を確認してから、オンに戻します。
Webhook イベントサブスクリプション
Webhook を作成および更新する場合は、関心のあるイベントを特定します。必要な数だけ選択します。イベント数を減らし、webhook を異なる命名スキームおよび異なるエンドポイントで論理的に分割すると、受信側でビジネスロジックをモデル化して、共有された機能でのフィルタリングおよびルーティングを減らすことができます。
イベントスコープ:すべてのイベントのスコープは、webhook の作成中に提供されるワークスペースに限定されます。つまり、そのワークスペース内のすべてのプロジェクトで実行されたアクションのイベントが送信されます。
プロジェクト
ファイル
フォルダー
コメント
メタデータ
コレクション
カスタムフィールド
共有
Webhook メッセージペイロード
すべての webhook ペイロードには、type フィールド(発生したイベントを示します)と resource オブジェクトが含まれています。resource オブジェクトには、イベントに関連する Frame.io リソースの type と ID が含まれています。
ペイロードの例
上記の file.created イベントの例では、resource.id は新しく作成されたファイルの ID を示します。さらに、workspace、project、および user オブジェクトも含まれます。これらには、関連する workspace.id、project.id および user.id が含まれています。これらの値を使用して、受信イベントをフィルタリングしたり、キャッシュされたデータをローカルで検索したりすることで、API 呼び出しを減らすことができます。
アドビは、サブスクライブされたリソースに関するリソース ID 以外の追加情報は含めません。
アプリケーションで追加情報やコンテキストが必要な場合は、API 呼び出しを行って、参照されているリソースに関する詳細情報を検索することをお勧めします。
セキュリティ
デフォルトでは、すべての webhook に署名キーがあります。この設定できない署名シークレットを使用して、リクエストが Frame.io から発生していることを確認できます。
設定した webhook のレスポンスペイロードには、この webhook に固有の署名シークレットが含まれます。このシークレットは、この初期 webhook 作成応答でのみ提供されるので、シークレットストレージまたは環境変数の安全な場所に保存してください。 後で使用して、webhook がアドビのサーバーから直接読み取られ、傍受や操作が一切行われていないことを確認してください。
Webhook 署名の確認
中間者攻撃や反射攻撃から統合を保護するには、wbhook ペイロードの署名を確認することが不可欠です。確認により、Webhook ペイロードが実際に Frame.io によって送信され、トランスポートでペイロードコンテンツが変更されていないことが確認されます。
POST リクエストには、次の HTTP ヘッダーも含まれます。
タイムスタンプは、送信 webhook が送信されたときの、Frame.io のシステムからのシステム時間です。これは、リプレイ攻撃を防ぐために使用できます。この時刻が現地時間から 5 分以内であることを確認することをお勧めします。
署名は、Webhook が最初に作成されたときに提供された署名キーを使用する HMAC SHA256 ハッシュです。
署名を確認するには、次の手順に従います。
指定された署名には、接頭辞 v0= が付きます。現在、Frame.io で署名リクエスト用に用意されているのはこれだけです。この接頭辞が計算された署名の先頭に追加されていることを確認してください。
再試行とログ記録
- 合計 5 回の試行(最初 + 4 回の再試行)
- 15 秒から開始される指数バックオフ(+ジッタ)
2xx以外のステータスまたは 5 秒を超えるタイムアウトにより、再試行がトリガーされます
Frame.io は、次を含んだ障害ログを保持します:webhook_id, account_id, event_type, resource_id, user_id
Webhook チュートリアル
手順 1:受信側の設定(URL を把握するために最初に実施します)
ここでは、webhook.site を使用しています。これにより、ペイロードの確認に使用できる、単回使用の webhook 受信者を簡単に作成し、実際のビジネスロジックなしで基本的な応答を送信できます。初めて https://webhook.site に移動すると、すぐにコピーして使用できる一意の webhook エンドポイントが作成されます。
この URL は、セッション固有です。

手順 2:サブスクライブするイベントの選択
このチュートリアルでは、シンプルにし、file.created イベントをサブスクライブするだけのためにこの webhook を設定します。Webhook 作成に使用する JSON ペイロードは、次のとおりです。
手順 3: Postman を使用して webhook リソースを作成
Postman を使用して、webhook リソースを作成する API 呼び出しを行い、ペイロードで webhook.site エンドポイントを提供します。
手順 4:テスト
Webhook サブスクリプションを作成し、webhook を受信するようにエンドポイントを設定したら、起動する原因となる適切なアクションを実行して最初の webhook をトリガーし、テストしてみましょう。
アドビのサンプルは file.created トリガーでトリガーするように設定されているので、先に進み、webhook が設定された対応するアカウントおよびワークスペース内の任意のプロジェクトに新しいアセットをアップロードしましょう。

その他のリソース
Ngrokは、一般にアクセス可能な URL で公開する必要がある webhook を操作する開発者にとって素晴らしいツールです。ローカル環境からインターネットへの安全なトンネルを作成し、ローカルサーバーを公開して webhook ペイロードをリアルタイムで受信できるようにします。
Hookdeckは、堅牢なイベントゲートウェイを提供することで、チームが webhook を確実に管理できるように設計されたプラットフォームです。Webhook 処理を一元化してイベントを見逃さないようにし、失敗した webhook のフィルタリング、キュー追加、再試行などの機能を提供します。