Was in einer Flow-JSON-Datei steht
Flow JSON hat zwei Pflichteigenschaften: version und screens. Jeder Screen hat eine id, einen optionalen title für die obere Leiste und ein layout vom Typ SingleColumnLayout, dessen children Komponenten sind: Texte, Eingabefelder, Auswahllisten, Datumsauswahl, Einwilligungen und genau ein Footer-Button.
Die Navigation steckt in Aktionen. Ein Footer mit navigate öffnet den nächsten Screen; auf dem letzten, als terminal markierten Screen schließt ein Footer mit complete den Flow und sendet den Payload zusammen mit dem Flow-Token an das Unternehmen. Seit Flow JSON 4.0 kann jeder Screen Felder früherer Screens mit ${screen.SCREEN_ID.form.field} lesen. Deshalb bleiben die navigate-Payloads in den Vorlagen leer, und alle Antworten landen im abschließenden complete-Payload.
- version: die Flow-JSON-Version, in allen Vorlagen „7.3“.
- screens: die geordnete Liste der Screens; der erste ohne eingehende Route ist der Einstiegsscreen.
- routing_model und data_api_version: nur für Flows, die Ihren Daten-Endpoint aufrufen.
- terminal und success: markieren den letzten Screen und ob ein Abschluss dort als Erfolg zählt.
Flows mit oder ohne Daten-Endpoint
Alle zwölf Vorlagen kommen ohne Endpoint aus. Sie brauchen keinen Server: Die Optionen stehen im JSON, Meta erzeugt das Routing-Modell, und Sie erhalten die Antworten an Ihrem Webhook, sobald der Kunde den Flow abschließt. Meta empfiehlt Flows ohne Endpoint immer dann, wenn keine Live-Daten nötig sind, weil sie schneller öffnen und schneller gebaut sind.
Ein Endpoint lohnt sich, wenn ein Screen Live-Daten braucht: freie Termine, wechselnde Preise, Lagerbestand oder eine Prüfung gegen das Kundenkonto. Dann nutzen die Screens data_exchange, der Flow braucht data_api_version und ein routing_model, und Ihr Endpoint muss jede Anfrage entschlüsseln und innerhalb des Zeitlimits von Meta antworten. Genau diesen Teil bauen und hosten wir für unsere Kunden.
Zeichenlimits und Regeln für Komponenten
Die meisten abgelehnten Flows scheitern an kleinen Regeln. Labels sind kurz: 20 Zeichen für Textfeld, Textbereich oder Dropdown, 30 für Radio- und Checkbox-Gruppen, 40 für die Datumsauswahl und 35 für den Footer-Button. Optionstitel dürfen 30 Zeichen haben, Beschreibungen 300. Überschriften fassen 80 Zeichen, Fließtext 4.096.
Pro Screen sind bis zu 50 Komponenten, ein Footer, zwei eingebettete Links, drei Bilder und fünf Einwilligungen erlaubt. Screen-ids bestehen nur aus Buchstaben und Unterstrichen, und SUCCESS ist reserviert. Arabische Labels zählen Zeichen, nicht Bytes. Der Validator prüft all das und nennt den Screen, den Sie korrigieren müssen.
Arabische Flows von rechts nach links für Kunden am Golf
Jede Vorlage gibt es in einer muttersprachlichen arabischen Fassung mit denselben Screens und Feldnamen. Ihr Webhook-Code verarbeitet so beide Sprachen ohne Änderungen. WhatsApp zeigt arabische Flows auf dem Smartphone des Kunden von rechts nach links an, und die Vorschau tut das ebenfalls.
Die Bibliothek enthält Anwendungsfälle, die am Golf wichtig sind: Anmeldung für Ramadan- und Eid-Angebote mit Versand nach dem Iftar, Tischreservierung im Restaurant, Anfragen zur Immobilienbesichtigung und eine KYC-Checkliste, die Kunden bittet, keine Ausweisfotos in den Chat zu schicken.
So senden Sie einen Flow an Kunden
Nach dem Veröffentlichen senden Sie den Flow als interaktive Nachricht vom Typ flow mit seiner Flow-ID, einem selbst erzeugten Flow-Token, einem kurzen Button-Text und dem ersten Screen. Die Bibliothek liefert den Nachrichten-Payload für jede Vorlage. Interaktive Nachrichten funktionieren nur im 24-Stunden-Kundenservice-Fenster; wenn Sie Kunden zuerst anschreiben möchten, hängen Sie den Flow an eine genehmigte Nachrichtenvorlage mit Flow-Button.
Schließt der Kunde ab, zeigt WhatsApp ihm eine Zusammenfassung seiner Antworten, und Sie erhalten den complete-Payload an Ihrem Webhook. Antworten Sie mit einer Bestätigung, die die nächsten Schritte nennt und erklärt, wie man ändert oder storniert.
