Inhaltsverzeichnis
Die eigentliche Integrationsfrage lautet nicht: Kann HubSpot angebunden werden?
In vielen mittelständischen Unternehmen entsteht bei einer neuen Systemanbindung schnell ein technischer Reflex: Es gibt eine API, also wird eine API gebaut. Oder eine App ist im Marketplace verfügbar, also wird die Standardintegration aktiviert. Beides kann richtig sein – aber nicht automatisch.
Die entscheidende Frage ist: Welche Art von Datenfluss braucht der Prozess wirklich? Geht es um einen begrenzten Austausch zwischen zwei Systemen, um eine belastbare Synchronisation mehrerer Objekte oder um einen individuellen Prozess mit eigener Geschäftslogik?
Die Antwort bestimmt, ob eine native Integration, HubSpot Data Sync oder eine individuelle Lösung mit API und Webhooks sinnvoll ist. Eine falsche Entscheidung zeigt sich oft erst später: durch doppelte Datensätze, unklare Datenhoheit, fehlende Fehlerbehandlung oder Workarounds in den Teams.
Stand: Oktober 2026.
1. Native Integration: der richtige Start bei klar begrenzten Anforderungen
Eine native Integration oder Marketplace-App ist meist der sinnvollste Einstieg, wenn das angebundene System bereits eine geprüfte Verbindung zu HubSpot anbietet und der Prozess relativ standardisiert ist. Typische Beispiele sind Kalender, Werbeplattformen, Newsletter-Tools oder Anwendungen mit klar definierten Kontakt- und Unternehmensdaten.
Der Vorteil liegt nicht nur in der schnellen Einrichtung. Auch Authentifizierung, grundlegende Feldzuordnung und Teile der Synchronisationslogik sind bereits vorbereitet. Das reduziert den individuellen Entwicklungsaufwand und erleichtert den Betrieb.
Das bedeutet jedoch nicht, dass eine Standardintegration ohne Konzeption auskommt. Vor der Aktivierung sollten mindestens diese Fragen beantwortet werden:
- Welches System ist für welche Information führend?
- Welche Objekte und Felder sollen tatsächlich übertragen werden?
- Ist die Synchronisation einseitig oder zweiseitig?
- Wie werden Datensätze einander zugeordnet?
- Was passiert bei widersprüchlichen Werten?
- Wie werden Fehler und ausgeschlossene Datensätze kontrolliert?
Gerade die letzte Frage wird häufig unterschätzt. Eine Integration kann technisch aktiv sein und trotzdem fachlich unvollständig arbeiten, wenn wichtige Datensätze wegen fehlender Identifikatoren, Filtern oder nicht passender Feldtypen ausgeschlossen werden.
2. HubSpot Data Sync: mehr als ein einfacher Feldabgleich
HubSpot Data Sync ist sinnvoll, wenn zwei unterstützte Anwendungen Datensätze regelmäßig miteinander abgleichen sollen. Nach Angaben von HubSpot kann die Synchronisation einseitig oder zweiseitig konfiguriert werden. Unterstützte Objekte können dabei – abhängig von der jeweiligen App – unter anderem Kontakte, Unternehmen und Deals sein.
Für die Praxis ist wichtig, Data Sync nicht als bloßen Importmechanismus zu betrachten. Der Dienst arbeitet mit einem internen Index, vergleicht Datensätze und verarbeitet zunächst eine initiale Synchronisation. Danach folgt der laufende Abgleich von Änderungen. Feldzuordnungen, Synchronisationsrichtung, Filter und Regeln zur Konfliktauflösung sind deshalb zentrale Bestandteile der Architektur.
Ein typisches Szenario ist ein Unternehmen, das HubSpot für Marketing und Vertrieb nutzt, während ein ERP-System Aufträge, Kundennummern oder kaufmännische Informationen verwaltet. Hier kann Data Sync eine gute Lösung sein, wenn:
- beide Systeme mit vergleichbaren Standardobjekten arbeiten,
- die Synchronisationsrichtung fachlich klar definiert werden kann,
- die unterstützten Matching- und Mapping-Regeln ausreichen,
- keine komplexe Transformation zwischen den Systemen erforderlich ist.
Bei größeren Datenbeständen sollte die initiale Synchronisation eingeplant und überwacht werden. HubSpot weist darauf hin, dass große Datenbanken und insbesondere Millionen von Datensätzen länger benötigen können. Nach dem Start darf die Integration daher nicht sich selbst überlassen werden. Ein sauberer Prozess umfasst Testdatensätze, einen kontrollierten Start, die Prüfung von Fehlern und ausgeschlossenen Datensätzen sowie eine fachliche Abnahme.
3. Individuelle API-Integration: wenn der Prozess nicht in ein Standardmapping passt
Eine individuelle API-Lösung ist nicht automatisch die bessere oder technisch anspruchsvollere Variante. Sie ist dann gerechtfertigt, wenn der Unternehmensprozess Anforderungen enthält, die mit einer nativen Integration oder Data Sync nicht zuverlässig abbildbar sind.
Das kann beispielsweise der Fall sein, wenn ein ERP mehrere Geschäftsvorgänge in einer eigenen Struktur führt, wenn Daten vor der Übergabe validiert oder angereichert werden müssen oder wenn mehrere Systeme in einer definierten Reihenfolge beteiligt sind. Auch individuelle Objekte, spezielle Zuordnungen und komplexe Berechtigungslogiken sprechen eher für eine eigene Integrationsarchitektur.
HubSpot stellt für solche Szenarien verschiedene APIs und Werkzeuge bereit. REST APIs können CRM-Objekte, Eigenschaften und Zuordnungen lesen oder schreiben. Für große Datenmengen stehen Bulk-Operationen zur Verfügung. Für ereignisbasierte Prozesse können Webhooks Änderungen an ein externes System melden.
Der entscheidende Unterschied: Eine API ist für den gezielten Zugriff und die Verarbeitung von Daten geeignet. Ein Webhook benachrichtigt dagegen über ein Ereignis. In einem belastbaren Datenfluss werden beide häufig kombiniert: Ein Ereignis löst eine Benachrichtigung aus, anschließend ruft ein Dienst die benötigten Daten ab, validiert sie und schreibt das Ergebnis in das Zielsystem.
4. Webhooks sind kein Ersatz für Datenmodell und Fehlerkonzept
Ein häufiger Implementierungsfehler besteht darin, Webhooks als vollständige Synchronisationslösung zu behandeln. Eine Benachrichtigung über eine Änderung enthält nicht automatisch alle Informationen, die das Zielsystem benötigt. Außerdem müssen Wiederholungen, verspätete Ereignisse, Reihenfolgen und nicht erreichbare Endpunkte berücksichtigt werden.
Für die Architektur bedeutet das: Ein Webhook braucht eine sichere Empfangsstelle, eine nachvollziehbare Verarbeitung, Protokollierung und eine Strategie für Fehlerfälle. Zusätzlich sollte klar sein, ob die Änderung nur gemeldet oder anschließend über die API nochmals verifiziert wird.
Auch die Auswahl der Ereignisse muss begrenzt werden. Zu viele abonnierte Änderungen können unnötige Last und schwer kontrollierbare Datenmengen erzeugen. Besser ist ein klar definierter Auslöser, etwa ein Statuswechsel, der für einen konkreten Folgeprozess relevant ist.
5. Die wichtigste Entscheidung: Datenhoheit vor Technik
Ob eine Integration stabil läuft, entscheidet sich selten zuerst an der Programmiersprache. Häufiger scheitert sie an ungeklärten Verantwortlichkeiten. Wenn beispielsweise sowohl HubSpot als auch das ERP eine Kundenadresse ändern dürfen, braucht es eine Regel: Welches System gewinnt bei einem Konflikt? Gilt diese Regel für alle Felder oder nur für bestimmte Bereiche?
Vor der technischen Umsetzung sollte deshalb eine einfache Datenmatrix erstellt werden:
- Objekt und Feld
- führendes System
- Quelle der Änderung
- Synchronisationsrichtung
- Matching-Schlüssel
- Validierungsregel
- Verhalten bei Fehlern und Konflikten
Diese Matrix macht sichtbar, ob eine Standardintegration ausreicht oder ob eine Transformations- und Routing-Schicht erforderlich ist. Sie verhindert außerdem, dass Teams später mit widersprüchlichen Annahmen arbeiten.
6. Ein pragmatischer Entscheidungsweg für mittelständische Unternehmen
Für die Auswahl hat sich ein stufenweises Vorgehen bewährt:
- Prozess abgrenzen: Beschreibe nicht „ERP an HubSpot anbinden“, sondern den konkreten Ablauf, etwa „neue Aufträge sollen nach erfolgreicher Prüfung als Kundenstatus in HubSpot verfügbar sein“.
- Daten und Objekte bestimmen: Kläre, welche Datensätze wirklich benötigt werden und ob ihre Beziehungen erhalten bleiben müssen.
- Standardfähigkeit prüfen: Gibt es eine native Integration oder einen Data-Sync-Konnektor, der Matching, Mapping, Filter und Konfliktregeln ausreichend abbildet?
- Ausnahmen dokumentieren: Jede notwendige Transformation, Berechnung oder Sonderlogik ist ein Hinweis auf eine individuelle Lösung.
- Betrieb mitplanen: Definiere Monitoring, Fehlerzustände, Wiederanlauf, Verantwortlichkeiten und einen Testprozess für Änderungen.
Wichtig ist dabei, nicht zu früh eine große Integrationsplattform aufzubauen. Ein klar begrenzter, gut überwachter Datenfluss ist oft wertvoller als eine umfassende Architektur, deren Verantwortlichkeiten niemand eindeutig erklären kann.
SMARTTEC-Empfehlung: klein starten, fachlich sauber entscheiden
Aus SMARTTEC-Sicht beginnt eine gute HubSpot-Integration nicht mit dem Endpunkt, sondern mit dem Prozess und dem Datenmodell. Für einfache, unterstützte Anwendungsfälle sollte zunächst geprüft werden, ob eine native Integration genügt. Wenn Datensätze zwischen zwei Systemen regelmäßig und mit überschaubaren Regeln abgeglichen werden, ist Data Sync häufig der pragmatische nächste Schritt.
Eine individuelle API- und Webhook-Architektur sollte dort eingesetzt werden, wo Geschäftslogik, Transformation, individuelle Objekte oder mehrere beteiligte Systeme dies wirklich erfordern. Dann gehören Datenhoheit, Validierung, Monitoring und Fehlerbehandlung von Anfang an zum Projekt – nicht als nachträgliche Ergänzung.
So entsteht keine Integration, die lediglich Daten bewegt, sondern ein verlässlicher Datenfluss, auf den Marketing, Vertrieb, Service und Management gleichermaßen aufbauen können.
