Créer une automatisation
Automatisations
Créer une automatisation
Créez une automatisation Famulor à partir d’une définition, activez-la et validez-la avec une véritable exécution de test.
POST
Créer une automatisation
Ce point de terminaison crée une automatisation à partir de sa définition (un déclencheur et ses étapes enchaînées), l’active, exécute une véritable exécution de test avec votre charge utile d’exemple, et rapporte le résultat étape par étape. L’exécution de test fait office de verrou : une automatisation dont le test échoue reste désactivée, et une automatisation déclenchée par un événement d’assistant n’est associée à l’assistant qu’après la réussite de son test.
Lorsqu’un modèle prêt à l’emploi correspond à votre besoin, l’appliquer est plus simple que d’écrire une définition depuis zéro.
Les étapes sont enchaînées au déclencheur dans l’ordre indiqué. La seule imbrication que vous écrivez vous-même se trouve à l’intérieur d’une étape qui en a besoin — les étapes conditionnelles d’une étape Déclencheurs pris en charge (
Le format de la définition
L’objetflow est la définition de l’automatisation. La forme privilégiée est une liste à plat :
BRANCH se placent sous onSuccessAction / onFailureAction. (Un arbre imbriqué manuellement, où chaque étape se trouve sous le nextAction de la précédente, est également accepté.)
Une définition remplace toujours l’automatisation entière — elle n’est jamais fusionnée. Un déclencheur sans étapes est rejeté (no_steps) : une automatisation qui ne fait rien ne peut pas être activée.
Déclencheurs pris en charge (trigger.settings)
Les étapes référencent la sortie des étapes précédentes par leur nom —
{{step_1['body']['field']}} pour les étapes HTTP (leur JSON s’imbrique sous body). Formes d’étapes courantes : requêtes HTTP, transformations de code, branchements, délais, étapes de réponse, et actions de la plateforme Famulor (envoyer un SMS/WhatsApp, démarrer un appel, remettre un lead en file d’attente). Le moyen le plus simple d’apprendre la forme exacte d’une étape est de lire une automatisation existante avec Récupérer une automatisation ou d’appliquer un modèle et d’inspecter ce qu’il a construit.
Corps de la requête
string
requis
Un nom court et lisible pour l’automatisation (255 caractères max.)
object
requis
La définition de l’automatisation —
{"trigger": {...}, "steps": [...]} comme décrit ci-dessus. 1 Mo max.object
Une charge utile d’exemple de forme réaliste pour l’exécution de test (ce que le déclencheur recevra). Pour les événements d’assistant, un exemple canonique construit à partir des propres variables de l’assistant est utilisé en cas d’omission. 256 Ko max.
integer
Requis pour les automatisations déclenchées par un événement d’assistant (
phoneCallEnded, inboundCall, newConversation, et bind_webhook) : l’assistant auquel cette automatisation s’associe. Elle commence à recevoir les événements réels de cet assistant une fois le test réussi. (Pour les déclencheurs de plateforme, sélectionner l’assistant dans settings.input.assistant du déclencheur fonctionne aussi — le paramètre explicite l’emporte.)string
Pour une définition déclenchée par webhook uniquement : l’associer à l’événement de fin de conversation de l’assistant. La seule valeur prise en charge est
conversation_ended. Nécessite assistant_id.boolean
Requis (
true) lorsque la définition contient des étapes qui envoient des messages ou des e-mails, démarrent des appels, ou effectuent des requêtes HTTP non-GET — l’exécution de test les exécute réellement.Réponse
Renvoie201 lorsque l’automatisation est active (active / active_untested), 200 lorsqu’elle a été construite mais que son exécution de test a échoué (test_failed), et 422 pour une définition qui n’a jamais atteint l’exécution de test (voir les codes d’erreur ci-dessous).
string
L’ID de l’automatisation créée
string | null
Pour les automatisations déclenchées par webhook (y compris celles de fin de conversation) : l’URL que les systèmes externes appellent pour la déclencher.
null pour les automatisations déclenchées par un événement d’assistant ou par une programmation.string
active — l’exécution de test a réussi ; l’automatisation est active (et associée, pour les événements d’assistant).
active_untested — le déclencheur ne peut pas être déclenché à la demande (programmations, intégrations externes) ; l’automatisation est active et armée, et le premier événement réel en fait la preuve.
test_failed — l’exécution de test a échoué ; l’automatisation est restée désactivée. Consultez test.steps pour la classification par étape.object
Le résultat de l’exécution de test
object | string | null
Pour les automatisations testées de manière synchrone (déclencheurs webhook et entrants) : ce que l’automatisation a répondu pendant l’exécution de test
object | null
Pour les automatisations déclenchées par un événement d’assistant :
{"type": "post_call" | "inbound" | "conversation" | "conversation_ended", "assistant_id": <id>, "bound": <bool>}. bound vaut true uniquement après un test réussi.Codes d’erreur (422)
Les échecs définitifs renvoient{"message": "...", "error": "<code>"} et rien n’est activé. Codes notables :