Verbinden Sie Web, App, Wallet, Kasse und Partnerfrontends mit derselben Mitglieds-, Regel- und Buchungslogik.
Web, App und Partnerportal können unterschiedliche Erlebnisse gestalten. Mitglied, Berechtigung und Buchung sollten dabei dieselbe fachliche Bedeutung behalten.
CRMProfile und Einwilligungen
ERPArtikel, Belege, Partner
POS / ShopKauf und Retoure
Mitglied · Regelentscheidung
Kontostatus · Ledger
Angebot · Einlösung
Web und AppKontostand und Vorteile
Wallet und KasseIdentifikation und Berechtigung
PartnerfrontendVereinbarte Programmaktion
Headless bedeutet, dass das Frontend die Darstellung übernimmt und bestätigte Fachfunktionen über die vereinbarten Schnittstellen nutzt.
Ein React- oder Next.js-Webfrontend, eine iOS-/Android-App und ein Partnerportal können jeweils eigene Nutzerwege haben. Die verbindliche Entscheidung zu Punkten oder Einlösung gehört in den dafür führenden Fachprozess. Eine zweite, abweichende Bonusberechnung im Frontend würde diese Trennung unterlaufen.
Mitglieder und Profile, Konten und Wallet-Bezüge, Regeln und Aktionen, Kampagnen und Benefits sowie analytische Ergebnisse haben unterschiedliche Aufgaben. Ein Frontend erhält jeweils den für seine Rolle bestätigten Zugriff. Sichtbarkeit einer Information und Berechtigung zu einer Aktion werden getrennt bewertet.
Navigation, Markenauftritt, verständliche Fehlerzustände und zugängliche Bedienung liegen beim jeweiligen Frontend. Apple-/Google-Wallet-Pässe oder optionale IoT-Zugänge benötigen ihren eigenen bestätigten Integrationsweg; Headless allein stellt diese Endgerätefunktionen nicht bereit.
| Weg | Typische Aufgabe | Was der Vertrag klärt |
|---|---|---|
| REST / JSON | Eine aktuelle Information abfragen oder eine definierte Aktion anfordern. | Version, Antwortsemantik, Berechtigung, Limits und Wiederholung. |
| Webhook | Eine andere Anwendung über ein bestätigtes Ereignis informieren. | Zieladresse, Signaturverfahren, Zustellstatus und Retry-Regel. |
| Pub/Sub / Event Stream | Mehrere Empfänger asynchron mit Ereignissen versorgen. | Ereigniskatalog, Reihenfolge, Deduplizierung und Replay. |
| Batch / SFTP | Große Bestände oder periodische Dateien austauschen. | Format, Vollständigkeit, Prüfsumme und Teilfehlerbericht. |
| Azure-Integrationsservices | Datenflüsse über beispielsweise Logic Apps oder Service Bus orchestrieren. | Konkrete Dienste, Verantwortlichkeit und Betriebsgrenzen. |
Eine POS-Abfrage muss nicht nacheinander Webhook, SFTP und Stream durchlaufen. Für jeden Datenfluss wird der passende Weg gewählt. Der Kassenaufruf und ein nächtlicher Finance-Export können unabhängig voneinander arbeiten.
Ein synchroner Aufruf braucht ein definiertes Zeitbudget und einen verständlichen Fehlerweg. Eine asynchrone Verarbeitung benötigt dagegen einen sichtbaren Zustell- oder Verarbeitungsstatus. „Angenommen“ und „fachlich gebucht“ sind nicht dieselbe Bestätigung.
Ein Mitglied anlegen, eine ungültige Angabe zurückweisen und eine wiederholte Anfrage erkennen: Diese drei Fälle gehören schon in den ersten Integrationstest.
Illustrativer Vertrag, keine veröffentlichte Produkt-API. Route, Datenfelder und Antwortcode sind Anschauungsbeispiele. Die Domain .invalid ist absichtlich nicht erreichbar. Es werden keine Requests ausgeführt.
POST /example/members
Content-Type: application/json
Authorization: Bearer DEMO_TOKEN
{"externalId":"DEMO-001","program":"DEMO"}
Illustrative Antwort: 201 Created
{"memberId":"M-DEMO-001","status":"created"}Für die Umsetzung gilt ausschließlich die freigegebene Spezifikation der unterstützten Version.
OAuth-2.0-Verfahren und Scopes, Mandantenbezug, Validierung, Versionsregeln und Rate Limits werden ausdrücklich beschrieben. Stabile fachliche Referenzen und die vereinbarte Idempotenz verhindern eine zweite Wirkung bei wiederholtem Aufruf. Ein Timeout sagt zunächst nur, dass der Aufrufer kein eindeutiges Ergebnis erhalten hat.
Das Developer Center beschreibt den Weg zur versionsgebundenen Spezifikation und zum vereinbarten Testzugang. Eine öffentlich freigegebene OpenAPI-Datei, Postman Collection oder ein SDK wird nur mit bestätigter Verfügbarkeit verlinkt. Die Sprachbeispiele dieser Seite sind keine SDK-Verfügbarkeitszusage.
SSO über einen bestätigten Identitätsanbieter, etwa Microsoft Entra ID, kann mit SAML oder OIDC vereinbart werden. Rollen begrenzen den fachlichen Zugriff.
MFA und Conditional Access werden passend zum Administrationszugang festgelegt.
Eine Integration erhält die für ihren Zweck nötigen Scopes und Datenbereiche. Geheimnisse gehören nicht in Frontend-Code oder frei zugängliche Beispiele.
Mandantentrennung wird auch für technische Aufrufer geprüft.
Transport- und Speicherschutz, Audit und Monitoring ergänzen den Zugang. Webhook-Authentizität, Zustellfehler und Wiederholung benötigen eigene Prüfungen.
Konkrete Verfahren und Algorithmen werden in der Architektur bestätigt.
Datenhoheit, Fachobjekt, Ereignis und erwartete Wirkung bestimmen.
Testmandant, Rollen, Zugänge und versionierten Vertrag bereitstellen.
Normalfälle, Fehler, Limits, Dubletten und Wiederanlauf nachstellen.
Pilot, Monitoring, Go-live und Rückfallweg gemeinsam freigeben.
Änderungen, Versionen und Zustellqualität dauerhaft betreuen.
Besprechen wir Ihre Zielgruppe, Ihre Datenquellen und den Ablauf, den Sie verbessern möchten. Daraus entsteht eine Demo, die zu Ihrem Programm passt.
Ein normaler Vorgang. Ein Sonderfall. Die beteiligten Systeme. Wir zeigen, wie Regeln, Kanäle und Kontrolle zusammenspielen.