Satzart Kuschick-Integration — Entscheidung & Design

Status: Entschieden — Mandat angenommen Datum: 2026-05-27 Kontext: Partner-Alignment xtoura, Surface 5 (unabhängige Buchungsmaske)

Hintergrund

Satzart braucht eine verbesserte Buchungsmaske für den xtoura-PIM-Relaunch, die in das Kuschick-Backend einspeist. Das Deal-Playbook empfahl ursprünglich, die Freelance-Anfrage abzulehnen, um Fokus auf Busflow zu erhalten. Nach Bewertung im laufenden Termin wurde anders entschieden: das Mandat wird angenommen, weil es bei klarer Scope-Trennung sowohl bezahlte Arbeit, strategische Positionierung als auch Wissens-Reuse für Busflow erzeugt.

Entscheidung

Scope

• Buchungsmaske: Spezifikation durch Julian (Form-Design, UX-Flow, Datenmodell). Implementierung durch Satzarts Entwickler.
• Endpoint + Kuschick-Integration: Bau als eigenständige Integrationsfähigkeit. Das konkrete Kuschick-Transportprotokoll ist offen und muss vor Implementierung geklärt werden.
• Spätere Folge-Erweiterung (separates Mandat): Der gleiche Busflow-owned Endpoint soll von der xtoura-App genutzt werden.

Scope-Korrektur nach Busflow-Grill

Der Service soll nicht mehr primär als Satzart-/Julian-eigener Endpoint gedacht werden, sondern als Busflow-eigene Integrationsfähigkeit, die von der xtoura-App oder einer externen Buchungsmaske konsumiert werden kann. Die Kuschick-Anbindung darf über den reinen Buchungs-Submit hinausgehen, wenn die zusätzlichen Satz-Typen direkt auf Busflows Vision einzahlen: Legacy-Coexistence, Zero-Downtime-Migration, Betreiber-Onboarding, Buchungs- und Zahlungsabgleich oder spätere Ablösung von Kuschick als System of Record.

Arbeitsgrenze: "Mehrere Dinge" heißt nicht "vollständiger Kuschick-Klon". Jeder zusätzliche Satz-Typ braucht einen Busflow-Zweck. Reine Legacy-Portalfunktionen ohne Busflow-Reuse, etwa Kundenkonto-Self-Service, Kataloganfrage oder Gutscheinverkauf ohne konkreten Migrations-/Coexistence-Nutzen, bleiben zunächst Kandidaten statt Scope.

System-of-Record-Entscheidung

Für den aktuellen Satzart-/xtoura-Fall bleibt Kuschick zunächst System of Record. Die Busflow-eigene API fungiert als kontrollierte Integrationsfassade vor Kuschick: Sie nimmt Form- oder App-Anfragen entgegen, normalisiert sie in Busflow-Begriffe, übersetzt sie in Kuschick-Satz-Typen und gibt stabile Antworten an den Client zurück.

Ein späterer Two-Way-Sync zwischen Busflow und Kuschick bleibt denkbar, ist aber nicht Teil des ersten Scopes. Für die aktuelle Aufwandsschätzung zählt nur die Richtung: externe Oberfläche → Busflow Integration API → Kuschick.

Migration-First Adapter Scope

Der breitere Kuschick-Adapter wird nicht nach "welche Satz-Typen existieren?" priorisiert, sondern nach "welche Satz-Typen helfen, Busflow automatisch mit Betreiber-Daten zu befüllen?". Besonders relevant sind daher voraussichtlich:

• Produktdaten und Produkte: Grundlage für TourTemplate, TourDeparture und spätere TourOffering-Projektionen.
• Stammdaten Zustiege: Grundlage für BoardingPoint und Commerce-seitige verfügbare Zustiege.
• Stammdaten Versicherungen / Zusatzleistungen: mögliche Grundlage für AncillaryCatalogItem oder integrationsspezifische Angebotsoptionen.
• Verfügbarkeit, Zahlungsarten, CRM, Sitzplatz/Sitzplatzauswahl und Buchung: notwendig für Coexistence, solange Kuschick operative Wahrheit bleibt.
• Buchungen ändern / Zahlung2: relevant für spätere Abgleich- und Delta-Szenarien, aber nicht automatisch MVP.

Niedriger priorisiert bleiben Satz-Typen, die vor allem Kuschick-Portal-Funktionen abbilden und Busflow nicht beim Datenaufbau, bei Migration oder bei kontrollierter Coexistence helfen.

Service Boundary: Integration, nicht Domain-Import

Der Kuschick-Adapter darf Endpunkte und Datenverträge für migrationsrelevante Daten vorplanen und bereitstellen, schreibt aber im ersten Schritt nicht direkt in Busflows echte Domain-Tabellen. Langfristig ist eine Übernahme in TourTemplate, TourDeparture, BoardingPoint, Commerce-Projektionen usw. möglich, aber diese Materialisierung gehört in eine separate Busflow-Migrations-/Importstrecke.

Die erste Schnittstelle bleibt daher bewusst eine Integrationsfassade:

1. Kuschick-Daten abrufen oder Kuschick-Buchungen auslösen.
2. Rohantworten und normalisierte DTOs in Busflow-nahen Begriffen bereitstellen.
3. Datenhoheit und Zielmodell je Anwendungsfall separat entscheiden.

Datenhoheit je Anwendungsfall

Es gibt keine globale Antwort auf "Kuschick vs. xtoura/PIM vs. Busflow als führende Datenquelle". Die Datenhoheit hängt vom Integrationsszenario ab:

• Aktueller xtoura-App-Fall: Die xtoura-App spricht verschiedene APIs an. Busflow ergänzt nur eine eigene API-Fassade; Busflow wird dadurch noch nicht zum System of Record.
• Einmalige Busflow-Migration: Kuschick-Daten können als Quelle für initiale Betreiber-Daten dienen, müssen aber vor Übernahme gemappt, geprüft und ggf. angereichert werden.
• Coexistence / Sync-Phase: Kuschick kann weiterhin operative Wahrheit für Teile des Geschäfts bleiben, während Busflow schrittweise einzelne Domänen übernimmt.
• Teilablösung: Ein mögliches Zielbild ist, Buchungs- und Abrechnungsteile aus Kuschick herauszulösen, während andere Kuschick-Daten weiterhin gelesen oder synchronisiert werden.

Konsequenz für die Aufwandsschätzung: Der aktuelle Service muss flexibel genug sein, mehrere Datenquellen und Zielrichtungen zu bedienen, darf aber nicht so tun, als sei die spätere Busflow-Migration schon entschieden.

Erster xtoura-App-Flow

Der erste konkrete xtoura-App-Flow über die Busflow-API ist der Kuschick-Buchungsflow. Die API soll dafür nicht als allgemeiner Datenaggregator für Reisecontent auftreten, sondern die für eine Buchung notwendigen Vorabfragen und den finalen Submit kapseln:

1. ADRESSFELDER — Pflichtfelder für Anmelder und Teilnehmer ermitteln.
2. VERFUEGBARKEIT — Reise- und Leistungsstatus, freie Kontingente und Preise prüfen.
3. SITZPLATZ / SITZPLATZAUSWAHL — Sitzplatzwünsche oder konkrete Sitzplatzauswahl abbilden.
4. ZAHLUNGSARTEN — für die Reise verfügbare Zahlungsarten anzeigen.
5. CRM — erlaubte CRM-/Marketingaktionen laden, falls im Formular benötigt.
6. BUCHUNG — nach außen als quote/validate und confirm modellieren; intern auf Kuschick buchungsart=Anfrage mit Preisrückgabe und danach buchungsart=Buchung mit Speicherung mappen.

Nicht Teil dieses ersten Flows: allgemeines xtoura-Reisecontent-Serving, Kundenkonto-Funktionen, Kataloganfragen, Gutscheinverkauf oder ein vollständiger Legacy-Datenexport.

Quote / Confirm Contract

Der quote/validate-Schritt erzeugt eine kurzlebige quoteId. confirm darf diese quoteId wiederverwenden, statt direkt vor dem Schreiben alle Prüfungen erneut vom Client auszulösen.

Die quoteId ist ein Validierungsartefakt, keine harte Reservierungsgarantie. Sie bindet mindestens:

• Operator-/Integration-Kontext;
• Reise und relevante Leistungs-IDs;
• Teilnehmerzahl und Zuordnung;
• ausgewählte Unterbringungen, Zusatzleistungen, Zustiege, Sitzplätze und Zahlungsart;
• berechnete Preis-/Zahlungsbedingungen aus Kuschick;
• Zeitpunkt der Kuschick-Prüfung und kurze TTL, z.B. ca. 5 Minuten.

confirm akzeptiert nur eine gültige, nicht abgelaufene quoteId und unveränderte Kernfelder. Wenn der Client relevante Felder ändert oder die TTL abläuft, muss ein neuer quote/validate-Schritt laufen. Dadurch bleibt das Frontend schnell, ohne alte Formularzustände blind in Kuschick zu schreiben.

Idempotency & Correlation

Der Adapter soll prüfen, ob Kuschicks fremdvorgang-Feld als externe Referenz für Idempotency und Korrelation genutzt werden kann. Wenn Kuschick dieses Feld speichert und in späteren Antworten oder Suchpfaden wieder auffindbar macht, wird es zum zentralen Schlüssel gegen Doppel-Submits und zur Klärung von provider outcome unknown.

MVP-Verhalten:

• pro quote/confirm-Flow eine stabile Busflow-Correlation-ID erzeugen;
• diese ID, soweit Kuschick-kompatibel, als fremdvorgang an Kuschick übergeben;
• alle Rohrequests, Rohresponses, Partner-Responses und Logs über diese ID verknüpfen;
• vor blindem Retry prüfen, ob derselbe fremdvorgang bereits erfolgreich verarbeitet wurde oder möglicherweise noch offen ist.

Offen: Kuschicks tatsächliches Verhalten zu fremdvorgang muss getestet werden. Entscheidend ist, ob das Feld gespeichert, eindeutig behandelt, angezeigt oder per Kunden-/Buchungssuche wieder auffindbar ist.

Credentials & Mandantenmodell

Kuschick-Zugangsdaten werden pro Veranstalter / Operator modelliert, nicht als globaler Satzart-Zugang. Jeder Operator erhält eine eigene Integration-Konfiguration mit Kuschick-Basis-URL, User und Secret/Passwort bzw. dem daraus abgeleiteten Key-Verfahren.

Das passt zu Busflows Multi-Tenant-Modell und verhindert vermischte Audit-Spuren:

• Requests können eindeutig einem Operator zugeordnet werden.
• Kuschick-Fehler, Buchungsnummern und Retry-Versuche bleiben mandantenscharf nachvollziehbar.
• Ein späterer Busflow-Migrationspfad kann dieselbe Operator-Integration wiederverwenden.
• Satzart/xtoura bleibt Client oder Integrationspartner, aber nicht Credential-Eigentümer für alle Veranstalter.

Partner API Auth

Für den MVP nutzt die xtoura/Satzart-Seite einen API-Key pro Partner-Operator-Integration. Es gibt also keinen globalen Satzart-Key für alle Veranstalter. Der Key identifiziert sowohl den Partner-Client als auch die konkrete Operator-Integration, gegen deren Kuschick-Zugang gearbeitet wird.

MVP-Key-Rotation:

1. Busflow erzeugt einen neuen zweiten aktiven Key für dieselbe Integration.
2. Satzart/xtoura deployt den neuen Key.
3. Für eine kurze Übergangszeit akzeptiert Busflow alten und neuen Key parallel.
4. Busflow deaktiviert den alten Key nach Bestätigung oder Ablauf der Grace Period.
5. Alle Requests bleiben über key_id, Operator, Partner und Integration auditierbar.

Keys werden nur gehasht gespeichert. Responses und Logs dürfen den Klartext-Key nie enthalten. Jeder Key braucht mindestens Status (ACTIVE, ROTATING, REVOKED), created_at, optional expires_at, last_used_at, Partner-ID, Operator-ID und Rate-Limit-Konfiguration.

OAuth/JWT bleibt ein späterer Ausbaupfad, wenn Busflow ein größeres Partner-Ökosystem oder echte Nutzerdelegation braucht. Praktisch würde das bedeuten: Satzart registriert sich als OAuth-Client, erhält Access Tokens für bestimmte Scopes und Operator-Integrationen, und Busflow validiert pro Request Token-Signatur, Scope, Tenant/Operator und Ablaufzeit. Das ist flexibler, aber für den ersten Satzart-MVP schwerer als notwendig.

Partner Network Boundary & Rate Limits

Für den MVP soll geprüft werden, ob Satzart/xtoura die Busflow-API ausschließlich serverseitig aus einem bekannten Backend aufrufen kann. Wenn ja, ist eine IP-Allowlist zusätzlich zum API-Key bevorzugt. API-Keys sollen nicht in Browser- oder App-Clients landen.

Die Rate Limits sollen großzügig ausgelegt werden und realistisch etwa 100 gleichzeitige Buchungsvorgänge pro Operator/Integration tragen können. Trotzdem sollten Limits nach Request-Art getrennt werden:

• read/cache endpoints: großzügig, da diese primär aus Cache liefern;
• polling endpoints: großzügig, aber mit kurzem Mindestintervall pro refreshJobId;
• refresh triggers: begrenzt, damit ein Client nicht permanent Kuschick live belastet;
• quote/validate: ausreichend hoch für parallele Formular-Abschlüsse;
• confirm: geschützt und separat limitiert, weil es provider-seitig echte Schreibwirkung hat.

Ziel ist nicht künstliche Knappheit, sondern Schutz vor Fehlkonfiguration, Polling-Schleifen und Provider-Überlastung.

API Contract Strategy: Lossless Adapter First

Die externe API soll nicht vorschnell alle Kuschick-Eigenheiten in ein generisches Busflow-Modell pressen. Für den ersten Anwendungsfall zählt, dass keine integrationsrelevanten Daten verloren gehen. Der Adapter darf daher Kuschick-spezifische Konzepte sichtbar halten, solange er sie stabil, dokumentiert und mandantenscharf bereitstellt.

Die Zielarchitektur ist zweischichtig:

1. System-specific Adapter API: Kapselt Auth, Transport, Satz-Typen, Fehlercodes und Roh-/Normalantworten pro Zielsystem. Diese Schicht ist verlustarm und kann von Satzart/xtoura sinnvoll genutzt werden.
2. Central Busflow Normalization Layer: Übersetzt aus einem oder mehreren system-specific Adaptern in Busflow-Domainbegriffe, Import-Jobs, Staging-Modelle oder spätere Commerce-/Backoffice-Commands.

Konsequenz: Der Kuschick-Adapter darf nur teilweise normalisieren. Er kann gemeinsame Hilfsstrukturen anbieten, etwa einheitliche Request-Metadaten, Cache-Keys, Operator-Kontext, technische Fehlerhüllen und grobe DTOs für Availability/Booking. Die vollständige Busflow-Domain-Normalisierung passiert später in der zentralen Busflow-Schicht, nicht im ersten Adapter.

API Documentation Requirement

Die Adapter-API muss von Anfang an maschinenlesbar und partnerfähig dokumentiert werden, idealerweise via Swagger/OpenAPI. Das ist kein späteres Developer-Experience-Polish, sondern Teil des Scopes: Satzart/xtoura muss verstehen können, welche Kuschick-nahen Felder stabil sind, welche Felder roh durchgereicht werden, welche Felder normalisierte Convenience-Felder sind und welche Fehler-/Offline-Zustände auftreten können.

Für jeden exponierten Endpunkt braucht die Spezifikation mindestens:

• Request-DTO inklusive Operator-/Integration-Kontext.
• Response-DTO mit getrennten normalized und raw/provider Anteilen, soweit sinnvoll.
• Cache-Verhalten: live, cached, stale-while-revalidate oder unavailable.
• Fehlerhülle mit provider-spezifischem Code und partnerfähiger Fehlermeldung.
• Dokumentierte Kuschick-Satz-Typen, die intern verwendet werden.

Ein eigenes Admin-/Debug-UI ist für den Partner-MVP nicht erforderlich. Für den ersten Schnitt reichen Swagger/OpenAPI, strukturierte Logs und gespeicherte Rohantworten. Supportfälle im Satzart-MVP bleiben zunächst Satzarts Verantwortung; Busflow stellt die technische Nachvollziehbarkeit bereit, aber kein fertiges Support-Cockpit.

Langfristig kann ein Debug-/Integrator-Cockpit ein eigener Busflow-USP werden: entweder als Busflow-Add-on für Legacy-Integrationen oder als kleines Mikroprodukt rund um Kuschick-/Legacy-Adapter, Cache-Status, Provider-Verfügbarkeit, Rohantworten und manuelle Klärfälle.

Caching, Preload & Intelligent Composition

Caching ist ein zentraler Bestandteil des Kuschick-Adapters. Kuschick berechnet Preise und Verfügbarkeiten nach aktuellem Verständnis einmal täglich; dieser Prozess ist langsam und für interaktive Frontends ungeeignet. Der Adapter soll deshalb nicht nur "durchreichen", sondern die Ausgangslage für das Formular intelligent vorbereiten.

Mögliche Strategien:

1. Scheduled Import: Ein geplanter Job lädt produkt-, leistungs-, zustiegs-, zahlungs- und verfügbarkeitsnahe Ausgangsdaten pro Operator vor. MVP-Takt: zweimal täglich, z.B. nachts um 02:00 und nachmittags um 14:00, damit die Formular-Ausgangslage bereits warm im Cache liegt.
2. On-Demand Cache Fill: Fehlende oder veraltete Daten werden beim ersten Zugriff live geholt und danach zwischengespeichert.
3. Booking-triggered Refresh: Wenn eine konkrete Buchung für eine Reise gestartet wird, prüft der Adapter, ob reisenahe Daten aktualisiert werden sollten. Die Aktualisierung läuft möglichst asynchron im Hintergrund und kann spezifisch auf diese Reise begrenzt werden.
4. Stale-while-revalidate: Das Frontend erhält schnell vorhandene Daten; der Adapter aktualisiert im Hintergrund, wenn Kuschick erreichbar ist.
5. Future Calculation Layer: Langfristig könnte Busflow Berechnungsgrundlagen importieren und Preise on the fly selbst berechnen. Das ist ein eigener Designpfad und nicht automatisch Teil des ersten Adapters.

Ziel für das Formular: möglichst wenige blockierende Frontend-Ladevorgänge. Der Adapter darf zusammengesetzte Formular-Initialisierungsdaten liefern, z.B. Pflichtfelder, Zahlungsarten, CRM-Optionen, verfügbare Zustiege, relevante Leistungen, Sitzplatzoptionen und Cache-Metadaten in einem partnerfähigen Read-Endpoint.

Das Formularmodell soll als UX-orientiertes Composite DTO gestaltet werden, nicht als Sammlung roher Kuschick-Fragmente. Es enthält weiterhin provider-spezifische IDs und Rohbezüge, aber bereitet sie so auf, dass Satzart/xtoura ein schnelles, intelligentes Formular bauen kann.

Mögliche Inhalte der ersten Formular-Initialisierung:

• technische Buchungsgrundlagen: Reise-ID, Leistungen, Unterbringungen, Zusatzleistungen, Zustiege, Zahlungsarten, CRM-Aktionen;
• UX-Metadaten: Feldgruppen, Feldreihenfolge, Labels, Pflichtfelder, sichtbare/ausblendbare Felder;
• Verfügbarkeits- und Preisstand: Kontingente, Preise, Cache-Alter, Refresh-Status;
• Sitzplatzmodell: Wunschdimensionen, konkrete Auswahloptionen, Zuschläge, provider-spezifische Sitzplan-IDs;
• Validierungsplan: welche Angaben lokal geprüft werden können und welche vor confirm erneut gegen Kuschick validiert werden müssen;
• Fehlermapping: partnerfähige Fehlermeldungen plus provider-spezifische Fehlercodes für Support;
• Roh-/Provider-Anteil: IDs und Daten, die für spätere Kuschick-Requests verlustfrei erhalten bleiben müssen.

Damit entsteht der erste konkrete Mehrwert gegenüber Kuschicks eigener Oberfläche: Das Frontend muss nicht mehrere langsame Einzelanfragen orchestrieren, sondern bekommt ein vorbereitetes, cache-bewusstes Formularmodell.

Für interaktive Formularausgangsdaten gilt als Ziel: Die Daten sollen höchstens ca. 5 Minuten alt sein. Wenn ein Client Daten anfragt und der Cache älter ist, antwortet die API trotzdem schnell mit den besten vorhandenen Daten und löst verpflichtend eine Hintergrundaktualisierung aus. Beim Abschicken validiert Kuschick hart gegen den aktuellen Stand, sofern Kuschick erreichbar ist.

Die API darf einen Hintergrund-Refresh nicht als "zweite Antwort" in derselben normalen HTTP-Response verstecken. Dafür braucht der Contract ein explizites Muster, z.B.:

• schnelle Initialantwort mit cacheStatus, generatedAt, stale und refreshJobId;
• MVP: Client-Polling auf refreshJobId;
• später optional Server-Sent Events/WebSocket für elegantere Live-Updates;
• oder ein gezielter refresh-Endpoint, wenn das Frontend aktiv eine Aktualisierung anstoßen will.

Die genaue Polling-Response muss in der API-Spezifikation sichtbar sein: PENDING, SUCCEEDED, FAILED, STALE_PROVIDER_OFFLINE o.ä. sowie der aktualisierte Cache-Zeitpunkt.

Raw Response Storage & Offline Resilience

Kuschick-Rohantworten sollen gespeichert werden. Das dient nicht nur Debugging, sondern ist Teil des Ausfallkonzepts, weil Kuschick erfahrungsgemäß zeitweise offline sein kann.

Der Adapter braucht daher ein solides Resilience-Modell:

• Rohantworten pro Operator, Satz-Typ, Request-Signatur, Zeitpunkt und Cache-Status speichern.
• Provider-Fehler, Timeouts und leere Antworten getrennt klassifizieren.
• Für read-only Ausgangsdaten stale Antworten ausliefern, wenn Kuschick offline ist und die Daten noch innerhalb einer akzeptierten Frischegrenze liegen.
• Für buchende Schreiboperationen keine stillen Cache-Fallbacks verwenden; hier muss klar zwischen "nicht möglich wegen Provider offline" und "Provider hat abgelehnt" unterschieden werden.
• Auditierbare Korrelation zwischen Client-Request, Kuschick-Request, Kuschick-Rohantwort und partnerfähiger Response.

Fehlersemantik:

• Read-only: bevorzugt schnelle Cache-Antwort mit generatedAt, cacheAgeSeconds, cacheStatus und ggf. providerRefreshPending.
• Write/confirm: synchron gegen Kuschick ausführen. Keine Cache-Bestätigung.
• Provider rejected: Kuschick hat erreichbar und eindeutig abgelehnt. Der Client darf davon ausgehen, dass keine bestätigte Buchung angelegt wurde.
• Provider unavailable: Kuschick war nicht erreichbar, bevor eine Schreiboperation gestartet oder angenommen wurde.
• Provider outcome unknown: Die Anfrage wurde an Kuschick gesendet, aber Busflow erhält keine eindeutige Antwort, z.B. Timeout, Verbindungsabbruch oder verzögerte Verarbeitung. Dieser Fall darf nicht als "nicht gebucht" behandelt werden, weil die Buchung in Kuschick später doch existieren könnte.

Für provider outcome unknown braucht der Adapter einen Klärpfad: Korrelation über Request-Signatur, potenziellen Fremdvorgang/Idempotency-Key, spätere Suche/Abfrage falls Kuschick das ermöglicht, und ansonsten manuelle Prüfung. Ziel ist, Doppelbuchungen durch blindes Retry zu vermeiden.

Privacy Modes & PII Storage

Für den Satzart-MVP soll die PII-Speicherung bewusst einfach und defensiv bleiben. Wenn Busflow hier nur als verarbeitendes Drittsystem ohne eigenes begründetes Interesse an langfristiger Speicherung agiert, sollen personenbezogene Buchungsdaten im Zweifel nicht dauerhaft gespeichert werden.

Der Adapter sollte deshalb perspektivisch Privacy Modes pro Integration unterstützen:

• No-PII Persistence: Read-only Produkt-, Verfügbarkeits-, Stammdaten- und Cache-Rohdaten dürfen gespeichert werden. Buchungsrequests und -responses werden für Logs redigiert; PII wird nicht dauerhaft persistiert oder nur flüchtig verarbeitet. Das ist der bevorzugte Satzart-MVP-Modus.
• Encrypted Short Retention: Buchungs-Rohdaten mit PII werden verschlüsselt und nur für eine kurze Debug-/Klärfrist gespeichert. Zugriff ist stark eingeschränkt und auditierbar.
• Busflow-owned Processing: Für spätere Busflow-eigene Flows kann eine weitergehende Speicherung gerechtfertigt sein, z.B. wenn Busflow selbst Buchungsanfragen annimmt, Migration/Staging betreibt oder als System of Record agiert. Dann gelten Busflows eigene Datenschutz-, Retention- und Löschkonzepte.

Unabhängig vom Modus: technische Logs dürfen keine Klartext-PII enthalten. Korrelation läuft über IDs, Hashes, Request-Signaturen und provider-spezifische Referenzen, nicht über Namen, E-Mail-Adressen oder Telefonnummern.

Busflow USP: Partial Independence from Kuschick

Ein strategischer Busflow-USP ist, Betreiber schrittweise unabhängiger von Kuschick zu machen. Das betrifft nicht nur Lesecaches, sondern perspektivisch auch den Buchungsfall: Wenn Kuschick temporär offline ist, soll Busflow Buchungsanfragen potenziell trotzdem annehmen können, statt den Vertrieb vollständig zu blockieren.

Diese Fähigkeit ist bewusst noch nicht final entschieden. Sie braucht einen separaten Drill-down, weil mehrere Verhaltensmodelle möglich sind:

• Strict Provider Confirmation: Buchung gilt erst, wenn Kuschick sie bestätigt. Niedriges operatives Risiko, aber keine echte Offline-Unabhängigkeit.
• Queued Booking Request: Busflow nimmt die Anfrage entgegen, markiert sie als wartend und synchronisiert später nach Kuschick. Gute Ausfalltoleranz, aber die Kundenerwartung muss klar als Anfrage/Reservierungsversuch formuliert sein.
• Busflow-owned Reservation Hold: Busflow hält Kapazität anhand frischer Cache-Daten und reconciled später gegen Kuschick. Starker USP, aber konfliktanfällig bei Parallelbuchungen außerhalb Busflow.
• Progressive Replacement: Busflow übernimmt bestimmte Buchungs-/Abrechnungsfunktionen selbst und nutzt Kuschick nur noch für verbleibende Legacy-Domänen. Strategisch interessant, aber außerhalb des Satzart-MVPs.

Für den Satzart-Wrapper darf diese Fähigkeit vorbereitet werden, muss aber in der Partner-API sauber als Zustand modelliert werden. Eine offline angenommene Buchung darf nicht so erscheinen, als sei sie bereits in Kuschick bestätigt.

Für die externe Satzart-API gilt zunächst eine engere Regel: Wenn Kuschick beim finalen confirm nicht erreichbar ist, liefert der Wrapper einen Fehler. Satzart erhält keine implizite Offline-Buchungsannahme, weil das Formular sonst Buchungen suggerieren könnte, die nicht in Kuschick angekommen sind.

Für Busflow-eigene Flows darf das Verhalten anders sein: Wenn Kuschick offline ist, kann Busflow eine Buchungsanfrage als eingegangen, aber Provider-Bestätigung ausstehend aufnehmen. Ein erster manueller Klärungsprozess kann per E-Mail laufen:

• Bei Kuschick-Ausfall: interne/operatorseitige E-Mail "Kuschick ist nicht erreichbar; neue Buchungsanfrage liegt vor; wir versuchen später erneut zu synchronisieren."
• Bei späterem Erfolg: E-Mail "Buchung ist jetzt in Kuschick angelegt."
• Bei späterer Ablehnung: E-Mail "Buchung konnte nicht automatisch hinzugefügt werden; bitte manuell übernehmen/klären."

Diese Busflow-Fähigkeit bleibt ein eigenes Produkt- und Prozessdesign und wird nicht automatisch in der Satzart-Partner-API freigeschaltet.

Partner Exposure vs. Busflow USP

Satzart soll zunächst nur einen wrapperartigen Zugriff auf die Ausgangslage und den vereinbarten Kuschick-Flow erhalten. Fähigkeiten, die Busflow als strategischen USP stärken, können intern vorbereitet werden, müssen aber nicht für Satzart exponiert werden.

Der Satzart-Flow umfasst den finalen confirm-Schritt, also das Schreiben einer echten Kuschick-Buchung. Ohne diesen Schritt wäre der Wrapper für das Buchungsformular nicht ausreichend wertvoll.

Die strategische Grenze liegt anders: Ein tiefer Buchungs-/Abrechnungs-Sync zwischen Kuschick und Busflow ist wertvoll, aber nicht Teil der Satzart-Schnittstelle. Satzart erhält den Formular-Wrapper für Kuschick; Busflow behält weitergehende Fähigkeiten wie laufenden Buchungsabgleich, Abrechnungsübernahme, Delta-Sync oder spätere Teilablösung als eigene Produktfläche.

Rechtliche Grundlage

Werkvertrag ohne zusätzliche Rechte-Übertragungs-Klausel. Nach deutschem Standardrecht beim externen Werkvertrag verbleibt damit das Urheberrecht beim Auftragnehmer (Julian). Satzart erhält ein einfaches Nutzungsrecht im Rahmen des vereinbarten Zwecks — keine Exklusivität, keine Ausschlussrechte gegen Julians eigene Wiederverwendung.

Konsequenz: Es ist keine künstliche Aufspaltung in "Library vs. Microservice" notwendig, um IP zu sichern. Der Service kann grundsätzlich als von Julian betriebene/besessene Komponente bereitgestellt werden; der Reuse für Busflow ist rechtlich unproblematisch.

Technisches Setup

Aspekt	Stand
Kuschick-Interface	Warnung: bisherige Annahme "SOAP, Standard-WSDL vorhanden" ist nicht durch die vorliegende Spezifikation belegt. Beschreibung XMLAnfrage.pdf beschreibt XML-over-HTTP via xmlanfrage.php?operation=<xmltext> mit Satz-Typen und MD5-Tages-Key. Vor Aufwandsschätzung und Implementierung muss geklärt werden, ob Satzart/Kuschick tatsächlich SOAP/WSDL bereitstellt oder ob der Adapter gegen diese XML-Anfrage-Schnittstelle gebaut werden muss.
Endpoint-Sprache/Stack	offen — Abstimmung mit Satzarts Stack im Detail-Review
Auth zu Kuschick	offen — im Detail-Review klären
Hosting-Modell	offen — bevorzugt Busflow-owned/betrieben; Satzart-Infra nur, wenn Projekt- oder Datenschutzanforderungen es erzwingen

Neue Architektur-Erkenntnis — Booking Integration Service

Der Integrationsservice ist nicht nur ein Formular-Endpoint, sondern der erste reale Spike für einen Booking Integration Service: ein buchungsnaher Service, der externe Buchungsmasken entgegennimmt, validiert, normalisiert und in ein Zielsystem schreibt.

Zielbild: Der generische Teil beschreibt die Busflow-nahe Buchungssemantik: Anfrage annehmen, Pflichtfelder validieren, Passenger/Booker/Trip/Seat/Ancillary-Daten normalisieren, Idempotenz sicherstellen, Fehler und Retry-Strategien behandeln, Audit-/Debug-Informationen speichern. Der Kuschick-Teil bleibt bewusst spezifisch: Transportprotokoll (SOAP/WSDL falls vorhanden, sonst XML-over-HTTP), Auth/Key-Generierung, Feldnamen, Pflichtfeldlogik, Statuscodes, proprietäre Datenkonstrukte und Kuschick-spezifische Workarounds.

Architektur-Hypothese: Nicht alles in einen neutralen "Booking API Wrapper" pressen. Besser ist eine klare Trennung:

1. Generic Booking Intake Service — Zielsystem-unabhängige Eingangs- und Normalisierungsschicht.
2. Kuschick Connector / Sidecar Service — Kuschick-spezifische Übersetzung, Transportkommunikation und Betriebslogik.
3. Future Busflow Connector — spätere Zielrichtung, wenn dieselbe oder ähnliche Buchungsmaske direkt in Busflow schreibt.

Diese Trennung hält Wiederverwendung möglich, ohne die Realität zu verstecken: Legacy-Systeme wie Kuschick werden immer spezifische Datenkonstrukte, Pflichtfelder, Fehlerfälle und Betriebsquirks haben.

Strategischer Nutzen

1. Bezahlte Arbeit + Beziehungspflege — Julian bleibt Go-To Partner für Buchungs- und Integrationsthemen bei Satzart.
2. Keine echte Konkurrenz zu Busflow — Satzarts Form bleibt ein "kostenloser USP" im PIM-Paket; Busflow arbeitet im eCommerce-/Buchungs-Layer ungleich detaillierter (Payment, Tickets, Dispatch, ...).
3. Kuschick-Knowhow auf bezahlter Basis — Transportprotokoll, Auth-/Key-Quirks, Satz-Typen, Datenmodelle, Retry-Strategien werden im Satzart-Projekt aufgebaut. Da das Urheberrecht bei Julian liegt, ist die Wiederverwendung in einem zukünftigen Busflow-eigenen Kuschick-Konnektor (Migrationsszenarien) unproblematisch.
4. Folgeauftrag-Pfad xtoura-App — Der Endpoint ist die Basis für eine spätere Integration mit der xtoura-App. Separater, bezahlter Auftrag.

Risiken & Trade-Offs

Risiko	Handhabung
Opportunitätskosten gegenüber Busflow	Akzeptiert unter Bedingung, dass andere, weniger wichtige Aktivitäten priorisiert reduziert werden. Vor Beginn: Audit der eigenen Wochenaufteilung.
Dauerhafte Maintenance-Verpflichtung	Service ist im Besitz von Julian → er ist langfristig Ansprechpartner. Bei wachsender Last: Übergabe-Option (Code-Übertragung an Satzart gegen Aufpreis) offenhalten.
Architektonische Festlegung auf Kuschick-Datenmodell	Akzeptiert. Der Service ist explizit Kuschick-spezifisch (kein neutraler Buchungs-API-Wrapper). Migrations-Brücken zu Busflow entstehen separat.

Offene Punkte (für Detail-Review mit Satzart)

• [ ] Tech-Stack des Satzart-Microservices / Endpoints
• [ ] Form-Spec: UX-Flow, Datenmodell, Pflichtfelder, Validierungsregeln
• [ ] Endpoint-Schnittstelle: Request/Response-Schema gegen die Form
• [ ] Boundary festlegen: Was gehört in den generischen Booking Intake Service, was in den Kuschick Connector / Sidecar?
• [ ] Kuschick-spezifische Datenkonstrukte katalogisieren: Pflichtfelder, Reise-/Termin-/Teilnehmerstruktur, Sitzplatzlogik, Zusatzleistungen, Agentur-/Kundendaten, Status- und Fehlercodes.
• [ ] Idempotenz- und Konfliktmodell definieren: doppelte Submit-Versuche, bereits belegte Plätze, Kuschick-originierte Parallelbuchungen, Storno/Änderung nach Submit.
• [ ] Verbindliches Transportprotokoll klären: SOAP/WSDL vs. XML-over-HTTP xmlanfrage.php?operation=<xmltext>.
• [ ] Auth-Mechanismus Richtung Kuschick klären: WS-Security/Token/Basic falls SOAP, sonst user + MD5-Key aus User, Passwort, Tagesdatum und Satz-Typ.
• [ ] Hosting/Deployment-Modell (Satzart-Infra vs. Julian-Infra)
• [ ] Vertrags-Text: Bestätigen, dass keine Exklusivitäts-/Rechte-Übertragungs-Klausel enthalten ist

Parallel-Evaluation (separate Arbeitsspur)

Während/nach Aufbau des Satzart-Service: bewerten, wie ein zukünftiger Busflow-eigener Kuschick-Sync gebaut werden kann. Ziel ist Wissens- und ggf. Code-Reuse — nicht Doppelarbeit. Diese Evaluation läuft auf Busflow-Zeit, nicht auf Satzart-Zeit.

Konkretes TODO für Busflow: Aus dem Satzart-Service ein Busflow-taugliches Integrationsmuster extrahieren: Welche Teile werden als generischer Booking Intake wiederverwendbar, welche bleiben pro Legacy-System als Connector/Sidecar spezifisch? Ergebnis sollte später entweder in eine eigene Integrationsspec oder in PRODUCT_migration-and-onboarding.md überführt werden.