Skip to main content
POST
Créer une automatisation
API Famulor 1.0 (héritée). Cette page concerne uniquement Famulor 1.0 (app.famulor.de) et est conservée pour la compatibilité. Pour la plateforme actuelle, consultez la référence API Famulor 2.0.
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.
L’exécution de test exécute réellement l’automatisation. Les définitions contenant des étapes qui envoient des messages ou des e-mails, ou démarrent des appels, sont refusées à moins que vous ne transmettiez explicitement confirm_side_effects: true — et si vous le faites, ces étapes envoient réellement pendant le test. Ciblez des destinataires qui vous appartiennent.

Le format de la définition

L’objet flow est la définition de l’automatisation. La forme privilégiée est une liste à plat :
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 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

Renvoie 201 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 :