> ## Documentation Index > Fetch the complete documentation index at: https://docs.famulor.io/llms.txt > Use this file to discover all available pages before exploring further. # Automation erstellen > Erstelle eine Famulor-Automation aus einer Definition, aktiviere sie und prüfe sie mit einem echten Testlauf. Dieser Endpunkt erstellt eine Automation aus ihrer Definition (Trigger und verkettete Steps), aktiviert sie, führt einen echten Testlauf mit deinem Sample-Payload aus und meldet das Ergebnis Schritt für Schritt. Der Testlauf ist das Tor: schlägt der Test fehl, bleibt die Automation deaktiviert; eine Assistant-Event-Automation wird erst nach bestandenem Test an den Assistant gebunden. Wenn eine fertige Vorlage passt, ist [Anwenden einer Vorlage](/de/api-reference/automations/apply-template) einfacher als eine Definition von Grund auf zu schreiben. Der Testlauf führt die Automation echt aus. Definitionen mit Steps, die Nachrichten oder E-Mails senden oder Anrufe starten, werden abgelehnt, sofern du nicht explizit `confirm_side_effects: true` setzt — und dann senden diese Steps während des Tests wirklich. Richte sie auf Empfänger, die dir gehören. ### Definitionsformat Das `flow`-Objekt ist die Definition der Automation. Bevorzugte Form ist eine flache Liste: ```json theme={null} { "trigger": { ... }, "steps": [ step1, step2, ... ] } ``` Die Steps werden in der angegebenen Reihenfolge an den Trigger gehängt. Nesting schreibst du nur dort, wo es nötig ist — bedingte Steps eines `BRANCH`-Steps unter `onSuccessAction` / `onFailureAction`. (Ein handverschachtelter Baum, in dem jeder Step unter dem `nextAction` des vorherigen liegt, wird ebenfalls akzeptiert.) Eine Definition ersetzt immer die gesamte Automation — sie wird nie gemerged. Ein Trigger ohne Steps wird abgelehnt (`no_steps`): eine Automation, die nichts tut, kann nicht aktiviert werden. #### Unterstützte Trigger (`trigger.settings`) | Trigger | pieceName / triggerName | Verhalten | | --------------------- | -------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Webhook | `@activepieces/piece-webhook` / `catch_webhook` | Du erhältst eine `webhook_url` für externe Systeme. Der Payload kommt gewrappt: Felder als `{{trigger['body']['field']}}`. Synchron mit deinem Sample getestet. | | Anruf beendet | `@famulor/piece-famulor` / `phoneCallEnded` | Erfordert `assistant_id`. Nach grünem Test an den Assistant gebunden. Payload-Felder liegen direkt auf dem Trigger: `{{trigger['extracted_variables']['x']}}`, `{{trigger['customer_phone']}}`, … | | Eingehender Anruf | `@famulor/piece-famulor` / `inboundCall` | Erfordert `assistant_id`. Läuft, bevor der Assistant antwortet; muss in einem Respond-Step enden, der eine flache Map von Strings zurückgibt. | | Neue Conversation | `@famulor/piece-famulor` / `newConversation` | Erfordert `assistant_id`. | | Conversation beendet | Webhook-Trigger + `bind_webhook: "conversation_ended"` | Erfordert `assistant_id`. Feuert, wenn ein Chat endet; Payload kommt gewrappt — Felder über `{{trigger['body']['...']}}`. | | Zeitplan | `@activepieces/piece-schedule` / `every_x_minutes`, `every_day`, … | Kann nicht on-demand gefeuert werden — aktiviert als `active_untested`; der erste geplante Lauf ist der Beweis (Runs prüfen). | | Externe Integrationen | eigener Trigger der Integration (neue Tabellenzeile, neuer CRM-Kontakt, neuer Lead, …) | Dein verbundenes Konto wird automatisch angehängt; fehlt es oder ist es abgelaufen, erhältst du `needs_connection` / `needs_reconnection` mit den genauen Schritten in der Famulor-App. Aktiviert als `active_untested`. | Steps referenzieren frühere Ausgaben über den Step-Namen — `{{step_1['body']['field']}}` für HTTP-Steps (JSON liegt unter `body`). Häufige Step-Formen: HTTP-Requests, Code-Transforms, Branches, Delays, Respond-Steps und Famulor-Plattform-Aktionen (SMS/WhatsApp senden, Anruf starten, Lead erneut in die Queue). Am einfachsten lernst du die genaue Form, indem du eine bestehende Automation mit [Automation abrufen](/de/api-reference/automations/get) liest oder eine Vorlage anwendest und das Ergebnis inspizierst. ### Request Body Ein kurzer, menschenlesbarer Name für die Automation (max. 255 Zeichen) Die Automation-Definition — `{"trigger": {...}, "steps": [...]}` wie oben beschrieben. Max. 1 MB. Ein realistisch geformter Sample-Payload für den Testlauf (was der Trigger empfängt). Bei Assistant-Events wird bei Weglassen ein kanonisches Sample aus den Variablen des Assistants verwendet. Max. 256 KB. Pflicht für Assistant-Event-Automationen (`phoneCallEnded`, `inboundCall`, `newConversation` und `bind_webhook`): der Assistant, an den die Automation gebunden wird. Er empfängt die echten Events erst nach bestandenem Test. (Bei Plattform-Triggern funktioniert auch die Auswahl des Assistants in `settings.input.assistant` — der explizite Parameter hat Vorrang.) Nur für webhook-getriggerte Definitionen: an das Conversation-Ended-Event des Assistants binden. Einziger unterstützter Wert: `conversation_ended`. Erfordert `assistant_id`. Pflicht (`true`), wenn die Definition Steps enthält, die Nachrichten oder E-Mails senden, Anrufe starten oder Non-GET-HTTP-Requests machen — der Testlauf führt sie echt aus. ### Response Liefert `201`, wenn die Automation aktiv ist (`active` / `active_untested`), `200`, wenn sie gebaut wurde, der Test aber fehlschlug (`test_failed`), und `422` für eine Definition, die den Testlauf nie erreicht hat (siehe Fehlercodes unten). Die ID der erstellten Automation Bei webhook-getriggerten Automationen (inkl. Conversation-Ended): die URL, die externe Systeme aufrufen. `null` bei Assistant-Event- und Schedule-Automationen. `active` — Testlauf bestanden; die Automation ist live (und bei Assistant-Events gebunden). `active_untested` — Trigger kann nicht on-demand gefeuert werden (Schedules, externe Integrationen); die Automation ist live und scharf, der erste echte Event ist der Beweis. `test_failed` — Testlauf fehlgeschlagen; Automation bleibt deaktiviert. Lies `test.steps` für die Klassifikation pro Step. Ergebnis des Testlaufs `SUCCEEDED`, `PAUSED`, `FAILED` oder `not_tested` (nicht testbare Trigger); selten `no_run`, wenn der Test keinen Ausführungsdatensatz erzeugt hat. `PAUSED` zählt als Erfolg: der Lauf wartet an einem Delay-Step auf die Zielzeit — alle Steps davor sind bereits gelaufen. Ergebnis pro Step des Testlaufs Der Step-Name (`trigger`, `step_1`, …) `SUCCEEDED`, `FAILED` oder `PAUSED` `ok`, `paused_at_delay` oder — bei Fehlern — `wiring_error` (Definition falsch: reparieren über [Automation aktualisieren](/de/api-reference/automations/update)), `missing_connection` (Konto muss zuerst in der Famulor-App verbunden werden), `missing_record` (Sample referenziert nicht existierende Daten — oft unkritisch). Fehlermeldung des Steps, falls fehlgeschlagen Bei synchron getesteten Automationen (Webhook- und Inbound-Trigger): was die Automation während des Testlaufs geantwortet hat Bei Assistant-Event-Automationen: `{"type": "post_call" | "inbound" | "conversation" | "conversation_ended", "assistant_id": , "bound": }`. `bound` ist nur nach grünem Test `true`. ### Fehlercodes (422) Harte Fehler liefern `{"message": "...", "error": ""}` und nichts wird aktiviert. Wichtige Codes: | error | Bedeutung | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `side_effects_require_confirmation` | Die Definition enthält Steps, die im Test echt senden würden — erneut mit `confirm_side_effects: true` versuchen, nachdem die Empfänger geprüft wurden. | | `no_steps` | Am Trigger hängen keine Steps. | | `invalid_definition` / `unsupported_trigger` | Der Definition fehlt der Trigger, oder der Trigger-Typ wird nicht unterstützt. | | `assistant_required` / `assistant_not_found` | Der Trigger braucht eine `assistant_id`, oder der Assistant gehört nicht zu deinem Account. | | `binding_conflict` | Der Assistant hat bereits eine Automation (oder einen Custom-Webhook) für dieses Event — ein Slot pro Event-Typ. Bestehende Automation aktualisieren oder zuerst löschen. | | `needs_connection` / `needs_reconnection` | Das Integrationskonto des Triggers muss zuerst in der Famulor-App verbunden (oder neu verbunden) werden — die Meldung enthält die genauen Schritte. | | `import_failed` / `publish_failed` / `create_failed` | Die Definition wurde abgelehnt oder konnte nicht aktiviert werden. | ```json 201 Created (Webhook, Test bestanden) theme={null} theme={null} { "automation_id": "f4EaLhOW2zoEsXXSOJP2r", "webhook_url": "https://automate.famulor.ai/api/v1/webhooks/f4EaLhOW2zoEsXXSOJP2r", "status": "active", "test": { "run_status": "SUCCEEDED", "steps": [ { "name": "trigger", "status": "SUCCEEDED", "classification": "ok", "error": null }, { "name": "step_1", "status": "SUCCEEDED", "classification": "ok", "error": null } ] }, "response": { "ok": "true", "echo": "hello" }, "binding": null } ``` ```json 201 Created (Schedule, active_untested) theme={null} theme={null} { "automation_id": "aB3xYz01MnOpQrStUvWxY", "webhook_url": null, "status": "active_untested", "test": { "run_status": "not_tested", "steps": [] }, "response": null, "binding": null } ``` ```json 422 Validation Error theme={null} theme={null} { "message": "This automation contains steps that would REALLY send messages, emails or start calls during the test run: Send SMS. Confirm with the user first — point those steps at a safe recipient the user owns — then retry with confirm_side_effects set to true.", "error": "side_effects_require_confirmation" } ``` Verwandte Seiten: [Vorlagen auflisten](/de/api-reference/automations/list-templates), [Vorlage anwenden](/de/api-reference/automations/apply-template) und [Authentifizierung](/de/api-reference/authentication).