Bidirektionaler OAuth-Sync, der nach 14 Tagen Live-Sandbox in Produktion lief — ohne Endlosschleife, ohne 401-Storm.
Erkens-Mandat aus dem Finanz-/Versicherungsbereich. Die Maklerverwaltung führt Bestand und Provisionen, GoHighLevel ist der CRM-Hub für Vertrieb und Innendienst. Vor dem Sync hat der Innendienst manuell zwischen beiden Systemen abgeglichen — mit allen Folgekosten, die das hat.
Ausgangslage
Die Maklerverwaltung des Mandanten ist Bestand- und Provisions-System (Anbieter-Klasse: Professional Works / assfinet / AMS). Hier liegen Verträge, Vertragsdaten, Provisionsläufe und der Abrechnungs-Trail.
GoHighLevel ist der CRM-Hub für Vertrieb und Innendienst — Pipeline, Kommunikation, Kampagnen. Die Datenfelder überlappen mit der Maklerverwaltung an genau den Stellen, an denen Verkauf auf Bestand trifft.
Vor dem Sync gleicht der Innendienst manuell ab. Vertriebspartner sehen nicht den vollständigen Kundenstand vor dem Gespräch. Compliance-Audit-Trail bricht regelmäßig — wenn nachträglich gefragt wird, welches System zu welchem Zeitpunkt welchen Stand hatte, ist die Antwort nicht reproduzierbar.
Architektur — Single-Refresh-Authority + Compare-Before-Write
Wir lösen die Race-Condition über drei Patterns, die zusammen wirken: Single-Refresh-Authority für OAuth-Tokens, Origin-Tagging mit Compare-Before-Write-Fingerprinting für Schreibvorgänge, Field-Ownership-Regeln pro Datenfeld.
- 01MaklerverwaltungOAuth-Token-Authority (Source of Truth für Refresh)
- 02n8n-Sync-LayerOrigin-Tagging + Compare-Before-Write
- 03SupabaseEU-Datenlayer mit pgvector für Kontext-Lookups
- 04GHLCRM-Hub mit Field-Ownership-Regeln
- 05Audit-LogVollständiger Trail für Compliance
Single-Refresh-Authority
Nur die Maklerverwaltung-Seite refresht OAuth-Tokens. GHL-Seite konsumiert. Verhindert konkurrierende Refresh-Calls und 401-Storms.
Compare-Before-Write + Origin-Tagging
Vor jedem Schreibvorgang wird der Hash des Soll-Zustands gegen den Ist-Zustand geprüft. Origin-Tag verhindert, dass das eigene Update als Fremd-Update zurückläuft. Damit kein Endlos-Loop.
Field-Ownership-Regeln
Pro Datenfeld ist genau ein System die Quelle. Konflikte werden nicht "last-write-wins" aufgelöst, sondern an die Ownership-Regel.
Was war schwierig
Zwei Wochen verbrannt, weil ich die Race-Condition zuerst falsch eingegrenzt habe. Mein erster Hypothesen-Pfad — die Token-Refresh-Konkurrenz — war nur die halbe Miete. Live-Sandbox gegen den echten Pool-Account hat den eigentlichen Bug aufgedeckt: ein Origin-Tag, das in einem Edge-Case nicht gesetzt war. Mock hätte es nie gefunden, weil Mocks die echten Race-Patterns nicht reproduzieren — der Live-Sandbox-Stress-Test gegen den echten Account schon.
Ergebnis
- Innendienst räumt nicht mehr hinter dem Vertrieb her
- Vertriebspartner sehen vollständigen Kundenstand vor jedem Gespräch
- Compliance-Audit-tauglich durch vollständigen Datenfluss-Trail
- Kein 401-Storm, keine Endlosschleife — sauber durch 14 Tage Live-Sandbox abgesichert
Was übertragbar ist
Das Pattern (Single-Refresh-Authority, Compare-Before-Write, Live-Sandbox-Validierung) trägt für jede CRM-↔-Drittanbieter-Integration mit OAuth. Ob Versicherungs-Maklerverwaltung, Beratungs-Kanzlei-Software, Branchen-ERP oder Marketplace-Backend — der Mock-vs.-Live-Sandbox-Unterschied ist überall derselbe: Mocks finden die Edge-Cases nicht.
Häufige Fragen
Ähnliches CRM-Sync-Mandat?
Sie haben ein vergleichbares OAuth-Integrations-Vorhaben — Maklerverwaltung, Branchen-ERP, Beratungs-Software gegen GHL/HubSpot/Pipedrive? Im Erstgespräch sortieren wir Token-Modell, Field-Ownership und Sandbox-Strategie. Am Ende wissen Sie, ob ein Pilot tragfähig ist.