Pour les développeurs
Utilisez un workflow IA comme une API
Déclencher, consulter les résultats, valider les approbations, récupérer les artefacts : tout en REST — sans avoir à gérer vous-même les appels de modèle, les réessais et les files d'attente.
# Déclencher une exécution POST /api/webhooks/{id}/trigger → {"executionId": "exec_51a2"} # Interroger le statut : cette fois-ci, arrêt sur une approbation humaine GET /api/v1/executions/exec_51a2 → {"status": "AWAITING_APPROVAL"} # Reprise après approbation (les valeurs peuvent être modifiées avant validation) POST /api/v1/approvals/{approvalId}/approve # Récupérer le résultat et les artefacts une fois terminé GET /api/v1/executions/exec_51a2/result GET /api/v1/executions/exec_51a2/artifacts
Parcours d'intégration
15 minutes, de la création du Webhook à l'obtention du premier résultat
Quatre requêtes HTTP suffisent à parcourir tout le processus, sans SDK ; tout langage capable d'émettre des requêtes peut s'intégrer.
01Créer un Webhook, obtenir l'URL et la KeyAjoutez un déclencheur Webhook à un workflow dans la console pour obtenir une URL dédiée ; créez ensuite une API Key avec la portée WEBHOOK_TRIGGER.
02Un POST déclenche l'exécutionLes champs JSON de premier niveau sont automatiquement mappés vers des variables de workflow de même nom ; vous pouvez aussi utiliser variableMapping pour un mappage explicite ; le payload est limité à 1MB.
03Interroger le statut d'exécution et récupérer le résultatUtilisez l'executionId renvoyé pour consulter le détail de l'exécution ; une fois terminé, récupérez la sortie depuis le point de terminaison result et téléchargez les fichiers depuis le point de terminaison artifacts.
04Les actions nécessitant une revue humaine passent par l'API d'approbationL'exécution s'arrête à une étape manual_approval ; utilisez le point de terminaison d'approbation pour lister les éléments en attente, approuver ou rejeter ; en cas de rejet ou de dépassement du délai, rien n'est modifié.
# Étape 2 : envoyer un POST depuis votre système curl -X POST https://your-host/api/webhooks/{id}/trigger \ -H "X-API-Key: <your-api-key>" \ -d '{"ticket_id": "T-1024", "lang": "zh"}' # Les champs de premier niveau sont automatiquement mappés vers des variables de workflow de même nom → {"executionId": "exec_51a2"} # Étape 3 : interroger le statut, puis récupérer le résultat une fois terminé curl https://your-host/api/v1/executions/exec_51a2/result \ -H "X-API-Key: <your-api-key>"
Liste des capacités
Six points qui comptent pour ceux qui écrivent du code
Étapes de code en bac à sable pour 7 langagesPython, JavaScript, TypeScript, Bash, Ruby, Lua et CLI sont tous utilisables ; les variables sont injectées via des variables d'environnement WF_VAR_*, avec un délai d'expiration de 30 secondes par défaut, et l'exécution en production a lieu dans un bac à sable Docker à sortie réseau contrôlée.
Définition en YAML, intégrée à votre flux GitUn workflow est un fichier YAML : commit, diff et retour arrière se font tous dans le dépôt que vous connaissez ; le canevas et le YAML sont synchronisés dans les deux sens, et vous pouvez modifier l'un ou l'autre.
Intégrez vos propres outils via MCPEnveloppez un service interne dans un MCP Server et attachez-le à un Agent : l'étape d'IA peut alors appeler directement votre système, sans attendre que la plateforme fournisse un connecteur.
Débogueur par points d’arrêt9 types de points d'arrêt : dès qu'un point est atteint, l'exécution se met en pause, et reprend une fois les variables modifiées ; après un échec, relancez depuis une étape donnée, les étapes LLM déjà terminées n'étant pas refacturées.
API v1 à 14 points de terminaison, moindre privilègeDéclencher une exécution, consulter les résultats, valider les approbations et télécharger les artefacts disposent chacun de leur propre portée de permissions ; combinez les 6 portées selon vos besoins et attribuez à chaque système intégré sa propre Key.
Déclenchement en chaîne DELAYED_COMPLETIONUne fois A terminé, B est déclenché automatiquement après N secondes, avec un plafond maxRuns configurable ; un long processus se découpe en plusieurs segments, dont on consulte séparément les journaux et les coûts.
Limites assumées
Trois choses, à dire d'emblée
Pour éviter de les découvrir à mi-intégration.
Pas de centaines de connecteurs SaaSLes appels aux systèmes externes s'écrivent dans des étapes de code, ou s'enveloppent en outil MCP attaché à un Agent ; pour une équipe qui écrit du code, cette étape se résume à quelques lignes de requêtes HTTP.
Pas d'API d'estimation des coûts avant exécutionLa consommation de tokens et le coût de chaque exécution sont enregistrés appel par appel, et la comptabilité a posteriori est fine ; mais avant l'exécution, aucun devis n'est disponible, et le contrôle du budget repose sur le contrôle d'approbation et maxRuns.
Les limites, affichées d'embléePayload Webhook limité à 1MB ; délai d'expiration par défaut de 30 secondes pour les étapes de code ; la signature HMAC-SHA256 n'est conservée qu'en mode de compatibilité, les nouvelles intégrations utilisant l'API Key.
Accès à la documentation
Trois articles à lire avant l'intégration
Référence de l'API v1Champs de requête et de réponse des 14 points de terminaison, codes d'erreur, et paramétrage des 6 portées de permissions.Ouvrir la documentation →Déclencheur WebhookObtention de l'URL et de la Key, règles de mappage des variables, mode de compatibilité HMAC et limite de 1MB.Ouvrir la documentation →Syntaxe YAMLLes 8 types d'étapes, et comment écrire les modificateurs condition, retry et manual_approval.Ouvrir la documentation →
Intégrez votre premier workflow à votre système
La formule Free permet déjà de construire un workflow et de le faire fonctionner manuellement ; passez à Pro lorsque vous avez besoin du déclenchement Webhook et de l'ordonnancement planifié.