Webhooks V4
Qu’est-ce qu’un webhook ?
Un webhook est un rappel HTTP de type push que Frame.io déclenche dès qu’un événement important se produit sur votre compte (par exemple, la fin du transcodage d’un nouveau fichier, l’ajout d’un commentaire ou la création d’un projet).
Au lieu d’interroger l’API, vous fournissez une URL HTTPS publique ; Frame.io envoie alors en temps réel une payload au format JSON à cette URL, ce qui vous permet de :
Pour en savoir plus sur ce qu’est un webhook et à quoi il sert, consultez la page https://docs.webhook.site/.
Vue d’ensemble des points d’entrée
Authentification : tous les points d’entrée V4 nécessitent un jeton d’accès OAuth 2.0 obtenu via l’Adobe Developer Console. Les jetons de développeur hérités et les JWT ne sont pas acceptés.
Modifications et mises à jour dans Frame V4
Les webhooks créés dans la version héritée sont transférés vers la version 4 avec les modifications suivantes :
- Structure de la payload : ajout de l’identifiant du compte à la payload.
- Modifications apportées aux points d’entrée : le
team_idn’est plus fourni dans la payload JSON, mais figure désormais dans le paramètre « path » de l’URL :https://api.frame.io/v4/accounts/:account_id/workspaces/:workspace_id/webhooks - Intégration API : en raison des modifications apportées à la structure de l’API, aux points d’entrée et aux méthodes d’authentification, tout code existant destiné aux webhooks entrants qui effectue des appels ultérieurs à l’API Frame.io pour l’enrichissement et la recherche de ressources doit être mis à jour.
- Types d’événements : les webhooks liés aux ressources ont été scindés en événements distincts pour les fichiers et les dossiers. Tous les webhooks de la version héritée et contenant des événements liés aux ressources doivent être mis à jour pour correspondre aux événements appropriés pour les fichiers et les dossiers.
Statut du webhook après la migration : lorsque votre compte passe à Frame.io V4, les webhooks existants des versions précédentes sont automatiquement désactivés. Cela vous permet de modifier les points d’entrée de vos webhooks et la logique d’intégration afin de les adapter aux mises à jour de la version 4 avant de les réactiver. Les webhooks qui n’ont pas été mis à jour pour être compatibles avec la version 4 rencontreront des erreurs s’ils sont activés sans avoir été modifiés en conséquence. Vous pouvez vérifier quels webhooks sont inactifs en consultant le champ is_active via l’API ou en vérifiant les paramètres de vos webhooks avant de les réactiver.
Abonnements aux événements de webhook
Lorsque vous créez et mettez à jour des webhooks, identifiez les événements qui vous intéressent. Choisissez-en autant que vous le souhaitez. Notez toutefois que l’expérience s’en trouve améliorée si vous vous abonnez à un nombre réduit d’événements, en répartissant vos webhooks de manière logique à l’aide de schémas de nommage distincts et de points d’entrée différents, afin de pouvoir modéliser votre logique métier côté réception et ainsi réduire le filtrage et le routage dans les fonctions partagées.
Portée de l’événement : tous les événements sont limités à l’espace de travail indiqué lors de la création du webhook. Cela signifie que des événements seront envoyés pour toutes les actions effectuées dans l’ensemble des projets de cet espace de travail.
Projets
Fichiers
Dossiers
Commentaires
Métadonnées
Collections
Champs personnalisés
Partages
Payload du message du webhook
Toutes les payloads des webhooks contiennent un champ type, qui indique l’événement qui s’est produit, ainsi qu’un objet resource. L’objet resource contient le type et l’ID de la ressource Frame.io associée à l’événement.
Exemple de payload
Dans l’exemple ci-dessus concernant l’événement file.created, resource.id indique l’ID du fichier nouvellement créé. En outre, les objets workspace, project et user sont inclus, avec les workspace.id, project.id et user.id correspondants. Ces valeurs permettent de réduire le nombre d’appels API en filtrant les événements entrants ou en consultant les données mises en cache localement.
Nous ne fournissons aucune information supplémentaire concernant la ressource souscrite, hormis son identifiant.
Si votre application a besoin d’informations ou de contexte supplémentaires, nous vous recommandons d’effectuer un appel API pour obtenir plus d’informations sur les ressources concernées.
Sécurité
Par défaut, tous les webhooks disposent d’une clé de signature. Ce secret de signature non configurable permet de vérifier que la requête provient bien de Frame.io.
La payload de la réponse pour le webhook que vous avez configuré contient le secret de signature propre à ce webhook. Ce secret n’est fourni que dans cette réponse initiale de création du webhook ; veillez donc à le conserver en lieu sûr dans votre référentiel de secrets ou dans vos variables d’environnement. Utilisez-le ultérieurement pour vérifier que le webhook provient bien directement de nos serveurs et qu’il n’a pas été intercepté ou altéré d’une quelconque manière.
Vérification des signatures des webhooks
Pour protéger une intégration contre les attaques de type « man-in-the-middle » et les attaques par rejeu, il est essentiel de vérifier la signature de la payload du webhook. La vérification permet de s’assurer que les payloads des webhooks ont bien été envoyées par Frame.io et que leur contenu n’a pas été modifié pendant le transfert.
La requête POST comprend les en-têtes HTTP suivants :
La date et l’heure correspondent à l’heure système des serveurs de Frame.io au moment où le webhook sortant est envoyé. Cela permet de prévenir les attaques par rejeu. Nous vous recommandons de vérifier que cette heure ne s’écarte pas de plus de 5 minutes de l’heure locale. La signature est un hachage HMAC SHA-256 généré à l’aide de la clé de signature fournie lors de la création initiale du webhook. Suivez ces étapes pour vérifier la signature :
La signature fournie est précédée de v0=. Pour l’instant, Frame.io propose une seule version pour la signature des requêtes. Assurez-vous que ce préfixe soit ajouté au début de votre signature calculée.
Nouvelles tentatives et enregistrements
-
Cinq tentatives au total (la première + 4 nouvelles tentatives)
-
Retard exponentiel à partir de 15 s (+ variation)
-
Un statut autre que
2xxou un délai d’attente supérieur à 5 secondes déclenche une nouvelle tentative.
Frame.io conserve un journal des erreurs avec : webhook_id, account_id, event_type, resource_id, user_id.
Tutoriel sur les webhooks
Étape 1 : configurer le serveur de réception (à effectuer en premier afin de connaître votre URL)
Ici, nous utilisons webhook.site, qui permet de créer facilement un récepteur de webhook à usage unique pouvant servir à inspecter les payloads et à envoyer des réponses simples, sans aucune logique métier. Lorsque vous accédez pour la première fois à https://webhook.site, un point d’entrée webhook unique est créé pour vous ; vous pouvez le copier immédiatement pour l’utiliser.
Cette URL est propre à votre session.

Étape 2 : choisir le ou les événements auxquels vous souhaitez vous abonner
Dans ce tutoriel, nous allons faire simple et configurer ce webhook pour qu’il se contente de s’abonner aux événements file.created. La payload JSON que nous utiliserons pour la création du webhook sera la suivante.
Étape 3 : créer une ressource webhook à l’aide de Postman
À l’aide de Postman, effectuez un appel API pour créer la ressource webhook, en indiquant le point d’entrée webhook.site dans la payload.
Étape 4 : tester !
Maintenant que vous avez créé l’abonnement au webhook et configuré les points d’entrée pour recevoir les webhooks, il est temps de le tester en déclenchant le premier webhook en effectuant l’action appropriée qui entraînerait son déclenchement.
Comme notre exemple a été configuré pour se déclencher via l’événement file.created, nous allons maintenant charger un nouveau fichier dans n’importe quel projet du compte et de l’espace de travail dans lesquels le webhook a été configuré.

Ressources supplémentaires
Ngrok est un outil formidable pour les développeurs qui travaillent avec des webhooks devant être accessibles via une URL publique. Il établit des tunnels sécurisés entre votre environnement local et Internet, ce qui vous permet de rendre votre serveur local accessible afin de recevoir des payloads de webhook en temps réel.
Hookdeck est une plateforme conçue pour aider les équipes à gérer efficacement les webhooks grâce à une passerelle d’événements robuste. Il centralise la gestion des webhooks, garantissant ainsi qu’aucun événement ne soit manqué, et propose des fonctionnalités telles que le filtrage, la mise en file d’attente et la reprise des webhooks ayant échoué.
Webhook.site est un outil exceptionnel pour le prototypage et le test des webhooks, offrant une plateforme simple, mais puissante permettant de capturer et d’analyser les requêtes HTTP envoyées à des URL uniques générées automatiquement.
Val.town est un excellent outil pour créer rapidement des prototypes de gestionnaires de webhooks, car il simplifie le processus d’écriture, de test et de déploiement de petites fonctions JavaScript et Python directement depuis le navigateur.