„Bitte einmal abtippen“ – so beginnt in vielen Betrieben der Weg einer Anfrage von der Website in den Auftrag. Die Nachricht kommt per E-Mail, jemand überträgt Name, Telefonnummer und Anliegen von Hand in die Auftrags- oder Branchensoftware, und erst dort beginnt die eigentliche Arbeit mit Termin, Angebot und Rückruf. Das kostet Zeit und erzeugt Tippfehler genau an der Stelle, an der ein neuer Kunde zum ersten Mal mit dem Betrieb zu tun hat. XICflow kann jede neue Anfrage zusätzlich an eine https-Adresse schicken, die Ihr Programm bereitstellt, und versieht jeden Aufruf mit einer Signatur. Dieser Beitrag erklärt, wann sich das lohnt, welche Angaben übertragen werden, warum die Signatur belegt, dass die Daten wirklich von Ihrer Website stammen, und was passiert, wenn das Programm einmal nicht antwortet. Dazu kommen die Pflichten aus der Datenschutz-Grundverordnung, die am empfangenden Dienst hängen, und ein Ablauf für den ersten Testlauf.
Wann sich das Weiterreichen lohnt
Für viele Betriebe genügt die Benachrichtigung per E-Mail.
Sie geht an eine Adresse Ihrer Wahl, enthält Name, E-Mail, Telefon, Nachricht sowie alle eigenen Felder, und ein Klick auf „Antworten“ erreicht direkt die anfragende Person (XICflow-Dokumentation). Kommen nur wenige Anfragen pro Woche und gibt es kein Programm, das sie weiterverarbeitet, ist das der einfachere Weg; wichtiger als der Übertragungsweg ist dann die Reaktionszeit, wie sie der Beitrag Anfragen beantworten: Reaktionszeit, die Aufträge sichert beschreibt. Anders sieht es aus, wenn Kunden, Vorgänge und Termine ohnehin in einem Programm verwaltet werden. Dann wird jede Anfrage ein zweites Mal erfasst, von Hand und mit dem Risiko, dass eine Ziffer in der Telefonnummer verrutscht oder eine Nachricht im Postfach liegen bleibt. Genau dieser Schritt fällt weg, wenn die Website die Daten direkt übergibt.
Wie verbreitet solche Programme sind, zeigt die Erhebung der Europäischen Union zur Nutzung von Informationstechnik in Unternehmen. Von den kleinen Unternehmen mit 10 bis 49 Beschäftigten (Eurostat) nutzten 2025 41,08 Prozent (Eurostat) eine Software zur Planung der Unternehmensressourcen, kurz ERP, und 24,69 Prozent (Eurostat) eine Software zur Kundenverwaltung, kurz CRM. Die Erhebung erfasst nur Unternehmen ab zehn Beschäftigten in ausgewählten Wirtschaftszweigen (Eurostat); für Kleinstbetriebe mit wenigen Mitarbeitenden liefert sie keine Zahl. Sie zeigt aber, dass Kundendaten in vielen Betrieben in einem eigenen System liegen und nicht nur im Postfach. Ob sich das Weiterreichen lohnt, hängt deshalb weniger von der Größe ab als von drei Fragen: Gibt es ein Programm, in dem die Anfrage weiterbearbeitet wird? Kann dieses Programm Daten über eine https-Adresse annehmen? Und kommen genug Anfragen, dass sich das Abtippen spürbar summiert?
- Ein Handwerksbetrieb legt jede Anfrage als Vorgang in seiner Auftragssoftware an, mit Kundennummer, Objektadresse und Wiedervorlage.
- Eine Hausverwaltung sammelt Schadensmeldungen aus dem Formular in ihrem Verwaltungsprogramm und ordnet sie dort dem Objekt zu.
- Ein Restaurant übernimmt Gruppenanfragen in sein Reservierungssystem, statt sie aus dem Postfach abzuschreiben – passend zur Gruppenseite für Weihnachtsfeiern.
- Ein Dienstleistungsbetrieb mit mehreren Mitarbeitenden verteilt Anfragen über eine Kundenverwaltung, in der Zuständigkeit und Bearbeitungsstand stehen.
- Ein Betrieb mit eigenen Formularen für Bestandskunden lässt Serviceanliegen direkt im Ticket- oder Auftragssystem ankommen, wie im Beitrag über Serviceformulare für Bestandskunden beschrieben.
Was XICflow an Ihr Programm übergibt
Eingerichtet wird das Weiterreichen im Bereich „Anfragen“. Unter der Benachrichtigungsadresse steht das Feld „Automation-Webhook (URL)“.
Dort tragen Sie die Adresse ein, die Ihr Programm für eingehende Daten bereitstellt; angenommen werden nur https-Adressen, und wer das Weiterreichen nicht braucht, lässt das Feld leer (XICflow-Dokumentation). Ab dem Speichern schickt XICflow jede neue Anfrage zusätzlich zur Liste und zur E-Mail als JSON per POST an diese Adresse. Übertragen werden der Anlass („form.submission“), die Kennung der Website, der Eingangszeitpunkt sowie die Anfrage selbst mit Name, E-Mail, Telefon, Nachricht, Adresse, allen eigenen Feldern und dem Namen des Formulars (XICflow-Dokumentation). Die Adresse gilt je Website. Wer mehrere Websites betreut, richtet sie für jede einzeln ein und kann so etwa die Anfragen zweier Standorte an zwei verschiedene Programme schicken.
{
"event": "form.submission",
"site": "ihre-website",
"submitted_at": "2026-10-25T08:14:03+00:00",
"submission": {
"id": "3f9c2a1e-7b4d-4c8e-9a51-2d6e8f0b1c47",
"name": "Vorname Nachname",
"email": "kontakt@kunde.invalid",
"phone": "030 23125 412",
"message": "Bitte um ein Angebot für das Streichen von zwei Räumen.",
"url": null,
"fields": {
"Objektart": "Wohnung",
"Wunschtermin": "November"
},
"form": "Angebotsanfrage"
}
}Für die Zuordnung im Programm helfen einige Einzelheiten. Die Kennung unter „id“ gehört zu genau einer Anfrage und eignet sich, um einen doppelt eingehenden Aufruf zu erkennen. Eigene Felder stehen mit ihrer Beschriftung unter „fields“; leer gelassene Felder werden nicht übertragen (XICflow-Dokumentation). Ein Formular kann bis zu 40 eigene Felder enthalten, eine Nachricht wird nach 5.000 Zeichen gekürzt, ein einzelnes eigenes Feld nach 2.000 Zeichen (XICflow-Dokumentation). Wer im Programm feste Spalten hat, benennt die Formularfelder sinnvollerweise so, wie sie dort heißen – das spart beim Empfänger eine Übersetzungstabelle. Zwei Normen beschreiben, was dabei technisch geschieht: POST bittet die Zieladresse, den mitgeschickten Inhalt nach ihren eigenen Regeln zu verarbeiten (RFC 9110), und JSON muss zwischen Systemen, die kein geschlossenes Ökosystem bilden, in UTF-8 kodiert sein (RFC 8259). Umlaute in Namen und Nachrichten kommen damit unverändert an, sofern das Programm UTF-8 liest.
Warum die Signatur die Echtheit belegt
Die Empfangsadresse Ihres Programms muss aus dem Internet erreichbar sein, sonst könnte XICflow sie nicht aufrufen. Damit kann sie grundsätzlich jeder aufrufen, der sie kennt.
Die Sicherheitsinitiative OWASP beschreibt einen Webhook-Empfänger deshalb als öffentliche, nicht authentifizierte Annahmestelle für POST-Aufrufe, solange die Authentifizierung nicht eigens ergänzt wird (OWASP). Ohne Prüfung könnte also jemand gefälschte „Anfragen“ in Ihr Programm schreiben: mit erfundenen Namen, mit Links auf fremde Seiten oder schlicht in großer Menge. Bei einer Kundenverwaltung, aus der Angebote und Rückrufe entstehen, ist das mehr als ein Ärgernis.
Die Prüfung übernimmt ein Verfahren namens HMAC, das RFC 2104 als Mechanismus zur Authentifizierung von Nachrichten mit kryptografischen Hashfunktionen beschreibt (RFC 2104). Das Prinzip: Zwei Seiten teilen ein Geheimnis und prüfen damit Informationen, die zwischen ihnen übertragen werden (RFC 2104). XICflow erzeugt dieses „Signatur-Geheimnis“, sobald Sie zum ersten Mal eine Adresse speichern, und zeigt es unter dem Feld an (XICflow-Dokumentation). Bei jedem Aufruf berechnet XICflow mit dem Geheimnis einen Prüfwert über Zeitstempel und Inhalt und schickt ihn in einer Kopfzeile mit. Ihr Programm rechnet mit demselben Geheimnis nach. Stimmen beide Werte überein, stammt der Aufruf von jemandem, der das Geheimnis kennt, und der Inhalt wurde unterwegs nicht verändert. Als Hashfunktion dient SHA-256, deren Ergebnis 256 Bit lang ist (RFC 4868). Das Bundesamt für Sicherheit in der Informationstechnik zählt SHA-256 zu den empfohlenen Hashfunktionen und sieht HMAC als sicher an, wenn eine solche Hashfunktion eingesetzt wird und der Schlüssel mindestens 128 Bit lang ist (BSI TR-02102-1).
X-XICflow-Timestamp
Der Zeitpunkt des Aufrufs als Unix-Zeitstempel in Sekunden. Er gehört zum signierten Text und lässt sich deshalb nicht austauschen, ohne dass die Prüfung scheitert.
X-XICflow-Signature
Der Prüfwert hinter „sha256=“, gebildet über Zeitstempel, einen Punkt und den unveränderten Rumpf. Ihr Programm rechnet ihn nach und vergleicht (XICflow-Dokumentation).
Signatur-Geheimnis
Steht in XICflow unter dem Webhook-Feld und wird mit „Kopieren“ übernommen. Es reist nicht mit dem Aufruf mit, sondern liegt auf beiden Seiten getrennt.
Die Signatur hat zwei Grenzen, die man kennen sollte. Erstens belegt sie die Echtheit, verschlüsselt den Inhalt aber nicht; ohne Verschlüsselung könnte jeder auf dem Übertragungsweg mitlesen (OWASP). Deshalb nimmt XICflow nur https-Adressen an. Die Verschlüsselung übernimmt dabei TLS, das nach seiner Spezifikation Mitlesen, Manipulation und gefälschte Nachrichten verhindern soll (RFC 8446); für Webhook-Empfänger empfiehlt OWASP TLS 1.2 oder höher mit einem Zertifikat einer vertrauenswürdigen Stelle (OWASP). Zweitens sagt eine gültige Signatur, wer die Daten geschickt hat, nicht, dass ihr Inhalt harmlos ist (OWASP). Was jemand ins Formular schreibt, bleibt eine Eingabe von außen und wird im Programm behandelt wie jede andere Eingabe.
So prüft das empfangende Programm
Wie die Prüfung eingerichtet wird, hängt davon ab, wie Ihr Programm Daten annimmt. Bietet es eine eigene Empfangsadresse mit Signaturprüfung an, tragen Sie dort das Geheimnis ein und folgen der Anleitung des Herstellers.
Betreiben Sie eine kleine Annahmestelle selbst oder lassen Sie sie bauen, setzen Sie die Prüfung in diesen Schritten um; Aufbau und Felder des Aufrufs stehen in der Schnittstellen-Dokumentation von XICflow.
- Rohen Inhalt sichern. Den Rumpf des Aufrufs so lesen, wie er ankommt, bevor ein Rahmenwerk ihn als JSON auswertet. OWASP rät ausdrücklich, den rohen Rumpf zu übergeben, bevor das Rahmenwerk ihn verarbeitet (OWASP); wer ihn erst einliest und neu schreibt, verändert Leerzeichen oder Reihenfolge, und die Prüfung scheitert.
- Kopfzeilen lesen. „X-XICflow-Timestamp“ trägt den Zeitstempel, „X-XICflow-Signature“ den Prüfwert hinter „sha256=“ (XICflow-Dokumentation).
- Nachrechnen. HMAC-SHA256 über Zeitstempel, einen Punkt und den unveränderten Rumpf bilden, mit dem Geheimnis als Schlüssel (XICflow-Dokumentation). Das Geheimnis wird dabei als genau die Zeichenfolge verwendet, die XICflow anzeigt, ohne Umwandlung.
- Zeitkonstant vergleichen. Den eigenen Wert mit dem gelieferten über eine Funktion vergleichen, deren Laufzeit nicht davon abhängt, an welcher Stelle sich zwei Werte unterscheiden.
- Zeitfenster prüfen. Aufrufe ablehnen, deren Zeitstempel mehr als eine kleine Toleranz von der eigenen Uhr abweicht (OWASP). Das verhindert, dass ein mitgeschnittener Aufruf später erneut eingespielt wird.
- Doppelte erkennen. Die Kennung aus „submission.id“ speichern und einen weiteren Aufruf mit derselben Kennung nicht noch einmal verarbeiten.
- Schnell antworten. Den Eingang sofort bestätigen und die eigentliche Verarbeitung danach erledigen, etwa über eine Warteschlange (OWASP).
import hashlib
import hmac
import time
# Zeichenfolge aus dem Feld „Signatur-Geheimnis“, unverändert übernommen
# und aus einer geschützten Konfiguration geladen, nicht im Quelltext
SECRET = load_secret("xicflow_webhook")
TOLERANCE_SECONDS = 300 # frei gewählter Beispielwert
def receive_enquiry(headers, raw_body: bytes) -> int:
timestamp = headers.get("X-XICflow-Timestamp", "")
signature = headers.get("X-XICflow-Signature", "")
if not timestamp.isdigit() or not signature.startswith("sha256="):
return 401
if abs(time.time() - int(timestamp)) > TOLERANCE_SECONDS:
return 401
expected = hmac.new(
SECRET.encode("utf-8"),
timestamp.encode("ascii") + b"." + raw_body,
hashlib.sha256,
).hexdigest()
if not hmac.compare_digest(expected, signature[len("sha256="):]):
return 401
enqueue(raw_body) # Verarbeitung danach, nicht in diesem Aufruf
return 200Für den Vergleich in Schritt 4 stellt Python die Funktion „compare_digest“ bereit; sie ist laut Dokumentation darauf ausgelegt, Zeitanalysen zu verhindern, und eignet sich damit für kryptografische Zwecke (Python-Dokumentation). In PHP übernimmt „hash_equals“ dieselbe Aufgabe; ein gewöhnlicher Vergleich braucht dagegen je nach Position der ersten Abweichung unterschiedlich lange und verrät so etwas über das Geheimnis (PHP-Handbuch). Für die Antwort an den Absender empfiehlt OWASP ein klares Schema: 200 erst, wenn der Eingang dauerhaft gespeichert oder eingereiht ist, 400 bei unbrauchbarem Inhalt und 401 bei falscher Signatur, jeweils ohne technische Einzelheiten im Antworttext (OWASP). Fehlt die Signatur oder passt sie nicht, soll die Antwort auch nicht verraten, woran es lag (OWASP).
Wenn die Prüfung scheitert
Was bei einem Ausfall passiert
Für jeden Aufruf hat Ihr Programm fünf Sekunden Zeit (XICflow-Dokumentation).
Antwortet es nicht oder ist es gerade nicht erreichbar, bleibt die Anfrage trotzdem in Ihrer Liste; einen zweiten Versuch unternimmt XICflow nicht (XICflow-Dokumentation). Dahinter steht eine klare Arbeitsteilung: Die Website speichert die Anfrage unabhängig vom Weiterreichen, die Benachrichtigung per E-Mail läuft ebenfalls getrennt davon, und das Weiterreichen ist eine zusätzliche Kopie. Fällt die Kopie aus, fehlt die Anfrage im Programm – verloren ist sie nicht. Daraus folgt eine einfache Regel: Die Liste in XICflow ist die Quelle, das Programm ist der Arbeitsplatz. Adressen im internen Netz spricht XICflow aus Sicherheitsgründen nicht an (XICflow-Dokumentation). Der Hintergrund: Ein Dienst, der Daten an frei eingetragene Adressen schickt, ist nach OWASP ein Werkzeug, das Angreifer auf interne Netze zu richten versuchen (OWASP). Ein Programm, das nur im Büronetz erreichbar ist, braucht deshalb eine Empfangsadresse, die aus dem Internet per https erreichbar ist.
Tabelle waagerecht wischen
| Situation | Was XICflow tut | Was Sie tun |
|---|---|---|
| Programm antwortet nicht binnen fünf Sekunden | Beendet den Aufruf, die Anfrage bleibt in der Liste | Empfänger so einrichten, dass er sofort bestätigt und danach verarbeitet |
| Programm wegen Wartung nicht erreichbar | Kein zweiter Versuch, E-Mail-Benachrichtigung wie gewohnt | Nach der Wartung Liste und Programm abgleichen |
| Adresse ohne https oder fehlerhaft | Speichert sie nicht und meldet „Bitte eine gültige https-URL eingeben.“ | Adresse aus dem Programm erneut kopieren |
| Adresse zeigt ins interne Netz | Ruft sie nicht auf | Eine aus dem Internet erreichbare https-Adresse verwenden |
| Geheimnis neu erzeugt, Empfänger prüft noch den alten Wert | Signiert mit dem neuen Wert, der Empfänger lehnt ab | Neuen Wert sofort hinterlegen, abgelehnte Anfragen aus der Liste nachtragen |
| Eintrag vom Spam-Schutz aussortiert | Speichert ihn nicht und reicht ihn nicht weiter | Nichts; Testanfragen mit echten Angaben senden |
Für den Abgleich stehen zwei Wege bereit. Die Liste lädt die 500 neuesten Eingänge (XICflow-Dokumentation), der CSV-Export umfasst bis zu 5.000 Einträge, beginnend mit den neuesten, archivierte eingeschlossen (XICflow-Dokumentation). Voreingestellt bleiben Anfragen 180 Tage gespeichert und werden danach automatisch gelöscht (XICflow-Dokumentation). Der Abgleich gehört deshalb in einen festen Rhythmus, etwa einmal pro Woche und nach jeder Wartung des Programms, und nicht erst ans Jahresende. Was im Programm aus einer Anfrage wird und wie lange sie dort bleibt, folgt eigenen Fristen; das behandelt der Beitrag Anfragen aufbewahren oder löschen: Fristen zum Jahresende.
Das Geheimnis wie ein Zugangsdatum behandeln
Wer das Signatur-Geheimnis kennt, kann Aufrufe erzeugen, die Ihr Programm für echt hält.
Das BSI formuliert es für alle Verfahren dieser Art: Die verwendeten Authentisierungsschlüssel sind ebenso gut zu schützen wie sonstige kryptografische Geheimnisse (BSI TR-02102-1). OWASP wird konkreter und empfiehlt, Webhook-Geheimnisse wie die Zugangsdaten einer Datenbank zu behandeln (OWASP). Praktisch heißt das: Das Geheimnis gehört in die geschützte Konfiguration des Empfängers oder in einen Passwortspeicher, nicht in eine E-Mail, nicht in ein geteiltes Dokument und nicht in den Quelltext.
In XICflow dürfen Eigentümer, Administratoren und Bearbeiter die Benachrichtigungsadresse und den Webhook ändern, Betrachter nicht (XICflow-Dokumentation). Löschen Sie die Adresse wieder, bleibt das Geheimnis erhalten; tragen Sie später dieselbe Adresse ein, funktioniert die Prüfung unverändert weiter (XICflow-Dokumentation). Besteht der Verdacht, dass das Geheimnis bekannt geworden ist, erzeugen Sie mit „Neu erzeugen“ ein neues. Der bisherige Wert wird damit sofort ungültig, und Aufrufe an einen Empfänger, der noch den alten Wert prüft, schlagen fehl. Hinterlegen Sie den neuen Wert deshalb direkt im Anschluss beim Empfänger.
- Das Geheimnis nur über „Kopieren“ übernehmen, nicht abtippen.
- Beim Empfänger in der geschützten Konfiguration ablegen, getrennt vom Quelltext.
- Weder das Geheimnis noch die Kopfzeile mit dem Prüfwert in Protokolle, Fehlermeldungen oder Tickets schreiben (OWASP).
- Über die Rollen im Team festlegen, wer den Webhook ändern darf.
- Jede Website hat ihr eigenes Geheimnis; ein Empfänger für mehrere Websites prüft je Website mit dem passenden Wert.
- Nach einem Personalwechsel mit Zugriff oder bei einem Verdacht das Geheimnis neu erzeugen und sofort beim Empfänger nachziehen.
Auftragsverarbeitung mit dem empfangenden Dienst
Mit dem Weiterreichen bekommen Name, E-Mail-Adresse, Telefonnummer und Nachricht einen weiteren Empfänger.
Sobald ein Anbieter das empfangende Programm oder den Server dafür betreibt – eine Kundenverwaltung aus dem Netz, ein Automatisierungsdienst, der die Daten weiterverteilt, oder ein Rechenzentrum –, verarbeitet er die Anfragen in aller Regel in Ihrem Auftrag. Dann gilt Artikel 28 DSGVO: Sie dürfen nur mit Auftragsverarbeitern arbeiten, die hinreichende Garantien für geeignete technische und organisatorische Maßnahmen bieten (DSGVO). Grundlage ist ein Vertrag, der unter anderem Gegenstand und Dauer, Art und Zweck der Verarbeitung, die Art der Daten und die Kategorien betroffener Personen festlegt (DSGVO). Wie ein solcher Vertrag aussieht und wie er ins Verzeichnis der Verarbeitungstätigkeiten passt, steht im Beitrag Auftragsverarbeitung: AVV und Verzeichnis im Griff. Betreiben Sie die Annahmestelle vollständig selbst, entfällt dieser Vertrag; die Verantwortung für ihre Sicherheit liegt dann allein bei Ihnen.
Drei weitere Pflichten hängen am Weiterreichen. Erstens die Datenminimierung: Personenbezogene Daten müssen dem Zweck angemessen und auf das notwendige Maß beschränkt sein (DSGVO). Ein Formular, das nur fragt, was für die Antwort nötig ist, reicht auch nur das weiter; wie man es so aufbaut, zeigt der Beitrag Vom Besuch zur Anfrage: Kontaktformulare richtig aufsetzen. Zweitens die Sicherheit der Verarbeitung: Zu den geeigneten Maßnahmen zählt Artikel 32 ausdrücklich die Verschlüsselung personenbezogener Daten (DSGVO). Die https-Pflicht des Webhooks und die Signatur sichern den Übertragungsweg; das Programm selbst schützt der Empfänger. Drittens die Information der Betroffenen: Nach Artikel 13 nennt die Datenschutzerklärung gegebenenfalls die Empfänger oder Kategorien von Empfängern (DSGVO). XICflow erzeugt für jede Website eine Datenschutzerklärung mit dem Hinweis auf die Verarbeitung der Formulardaten (XICflow-Dokumentation); ob dort auch der empfangende Dienst genannt ist, prüfen Sie, bevor Sie das Weiterreichen einschalten.
Der Weg zum ersten Testlauf
- Empfangsadresse besorgen. Die passende Adresse bekommen Sie von dem Programm, das die Anfragen entgegennehmen soll (XICflow-Dokumentation). Sie beginnt mit https und ist aus dem Internet erreichbar.
- Adresse eintragen. Im Bereich „Anfragen“ die Website wählen, die Adresse in das Feld „Automation-Webhook (URL)“ einfügen und speichern.
- Geheimnis übernehmen. Das nun angezeigte „Signatur-Geheimnis“ mit „Kopieren“ übernehmen und beim Empfänger in der geschützten Konfiguration ablegen.
- Prüfung einschalten. Beim Empfänger die Signaturprüfung aktivieren oder nach den Schritten oben umsetzen und Aufrufe ohne gültige Signatur ablehnen.
- Website veröffentlichen. Nur eine veröffentlichte Website nimmt Anfragen entgegen; nach dem Einfügen eines Formulars erneut veröffentlichen (XICflow-Dokumentation).
- Testanfrage senden. Mit echten Angaben, ohne Links in der Nachricht und nicht schneller als drei Sekunden nach dem Laden der Seite, sonst sortiert der Spam-Schutz den Eintrag aus (XICflow-Dokumentation). Das Formular zeigt die Bestätigung auch bei aussortierten Einträgen; entscheidend ist der Blick in die Liste.
- Beide Seiten vergleichen. Steht die Anfrage in der Liste und im Programm, mit allen Feldern und korrekten Umlauten? Erst dann ist die Verbindung fertig.
- Abgleich einplanen. Einen festen Termin setzen, an dem Liste und Programm verglichen werden, und eine Person benennen, die ihn wahrnimmt.
Mit XICflow liegen Formular, Anfragenliste, Benachrichtigung und Weiterreichen an einem Ort. Was die Plattform darüber hinaus übernimmt, zeigt die Übersicht der Leistungen; Liste, Benachrichtigung, Export und Webhook-Feld erklärt das Kapitel Anfragen und Team der Dokumentation, und wie eine Website mit XICflow entsteht, erklärt So funktioniert’s. Ob aus einer weitergereichten Anfrage ein Auftrag wird, entscheidet danach nicht mehr die Technik, sondern die Antwort des Betriebs – sie kommt nur schneller in Gang, wenn niemand mehr abtippen muss.