Schnittstellen für HubSpot: Systeme sauber anbinden
ERP, Buchhaltung, Shop oder Telefonie an HubSpot anzubinden ist selten eine einzige Frage. Für manche Tools gibt es einen fertigen Connector, andere brauchen eine Middleware, und für ein eigenes Fachsystem baut man die Schnittstelle von Hand. Dieser Überblick zeigt, was wann sinnvoll ist und woran der Aufwand hängt.
Was eine HubSpot-Schnittstelle eigentlich meint
Wenn jemand nach einer HubSpot-Schnittstelle fragt, steckt dahinter fast immer dieselbe Aufgabe: Ein zweites System soll mit HubSpot Daten austauschen. Ein Kontakt, der im Shop kauft, soll in HubSpot auftauchen. Eine Rechnung aus dem ERP soll den passenden Deal auf 'gewonnen' setzen. Ein Anruf soll an der richtigen Kontaktzeitachse landen.
Für diese Aufgabe gibt es drei Wege. Der erste ist ein fertiger Connector aus dem HubSpot-Marketplace, den ein Anbieter pflegt. Der zweite ist eine Middleware, die als eigene Schicht zwischen den Systemen sitzt und Daten unterwegs umbauen kann. Der dritte ist eine eigene Schnittstelle, direkt über die APIs gebaut. Welcher Weg passt, hängt am Tool, an der Datenmenge und daran, wie viel Logik zwischen den Systemen liegen soll.
Geht es dir konkret um n8n als Verbindungsschicht, findest du die Details im Ratgeber zur n8n-HubSpot-Integration. Für eine feste, dauerhafte Verbindung mit eigenen Endpunkten ist die CRM-Integration der passende Rahmen. Steht dagegen ein kompletter Wechsel des Systems an, zeigt der Leitfaden zur CRM-Migration, wie der Umzug ohne Datenverlust läuft.
Welche Systeme typischerweise an HubSpot laufen
Die Fälle wiederholen sich. Diese sechs Kategorien decken den Großteil dessen ab, wonach in der Praxis gefragt wird.
ERP und Warenwirtschaft
Aufträge, Rechnungen, Lieferstatus und Umsatz liegen im ERP, die Vertriebssicht in HubSpot. Ziel ist meist, den Deal in HubSpot auf 'gewonnen' zu setzen, sobald im ERP eine Bestellung bestätigt ist, und Kundenstammdaten in eine Richtung sauber zu halten.
Buchhaltung
Lexoffice, sevDesk oder DATEV brauchen die Rechnungsempfänger, HubSpot den Zahlungsstatus. Für Lexoffice gibt es einen fertigen Marketplace-Connector, bei DATEV läuft die Anbindung fast immer über eine Middleware oder eine eigene Schnittstelle.
Shop-Systeme
Shopify, WooCommerce und Shopware bringen entweder eine native HubSpot-Integration mit oder lassen sich über ihre API anbinden. Typisch ist der Sync von Kunden, Bestellungen und Warenkorb-Abbrüchen, damit Marketing und Vertrieb auf denselben Datenstand schauen.
Telefonie
Aircall, Sipgate oder Placetel protokollieren Anrufe direkt an der HubSpot-Kontaktzeitachse. Für die gängigen Anbieter gibt es Connectoren im Marketplace, bei einer Telefonanlage im Haus wird es ein API-Projekt.
Support und Ticketing
Zendesk, Freshdesk oder ein eigenes Ticketsystem sollen Tickets und deren Status neben dem Deal zeigen. So sieht der Vertrieb offene Support-Fälle, bevor er einen Kunden auf ein neues Angebot anspricht.
Eigene Fachsysteme und Datenbanken
Branchensoftware, ein selbst gebautes Portal oder eine Produktdatenbank haben selten einen fertigen Connector. Hier gehe ich über die jeweilige API oder direkt auf die Datenbank und baue die Brücke zu HubSpot von Hand.
Für ein eigenes Fachsystem ohne fertigen Connector führt der Weg über eine individuell gebaute Anbindung, über die sich auch Sonderobjekte sauber abbilden lassen.
Drei Wege, ein System anzubinden
Vom fertigen Connector bis zur eigenen Schnittstelle. Die Frage ist nicht, welcher Weg der beste ist, sondern welcher zu deinem Fall passt.
Nativer Marketplace-Connector
Ein gängiges Tool mit gepflegter HubSpot-Integration, Standard-Feldern und ohne Sonderlogik.
Gering. Verbinden, Felder zuordnen, testen. Meist an einem Tag eingerichtet.
Festes Feld-Mapping. Kein Umrechnen, kein Zusammenführen aus mehreren Quellen, keine Bedingungen.
iPaaS / Middleware
Kein passender Connector, oder Daten müssen unterwegs umgebaut, gefiltert und angereichert werden. Ein Ablauf zieht sich über mehrere Systeme.
Mittel. Ein paar Tage bis zu einer Woche, je nach Zahl der Objekte und Regeln.
Braucht Betrieb und Überwachung. Bei sehr hohen Datenmengen oder harten Echtzeit-Anforderungen stößt es an Grenzen.
Eigene Schnittstelle
Feste, dauerhafte Verbindung mit eigenen Endpunkten, viel Datenvolumen oder Anforderungen, die kein Baukasten abdeckt.
Höher. Wird als kleines Entwicklungsprojekt geplant, dafür genau auf den Fall zugeschnitten.
Mehr Vorlauf und Wartung. Lohnt sich erst, wenn Standard und Middleware nicht mehr tragen.
Was den Aufwand bestimmt
Zwei Schnittstellen können nach außen gleich aussehen und im Aufwand weit auseinanderliegen. Diese vier Punkte machen den Unterschied.
Richtung des Syncs
Ein Feld nur von A nach B zu schicken ist deutlich einfacher als beide Seiten synchron zu halten. Beim Zwei-Wege-Sync muss geklärt sein, welche Seite bei einem Konflikt gewinnt, und der Ablauf braucht Schutz gegen Endlosschleifen.
Standard- oder Custom Objects
Kontakte, Firmen und Deals decken die HubSpot-Nodes und die meisten Connectoren ab. Sobald Verträge, Anlagen oder Projekte als Custom Objects abgebildet werden, läuft es über die HubSpot-API und die Associations, was den Aufwand erhöht.
Datenmenge und Timing
Ein paar hundert Datensätze am Tag sind unkritisch. Bei Zehntausenden greifen HubSpots API-Limits, dann braucht es Batch-Verarbeitung und Wiederholungen. Echtzeit ist teurer als ein Abgleich, der alle paar Minuten oder nachts läuft.
Fehlerbehandlung
Der teure Teil ist nicht der Normalfall, sondern was bei einem API-Ausfall, einem doppelten Datensatz oder einem falschen Format passiert. Eine Schnittstelle, die Fehler meldet und nichts still verschluckt, kostet Vorlauf, spart aber später die Datenbereinigung.
So gehe ich bei einer Anbindung vor
Der größte Teil der Arbeit liegt vor der ersten Zeile Code. Wer die Richtung sauber klärt, spart sich später die Fehlersuche in den Daten.
Bestandsaufnahme der Systeme
Zuerst schauen wir, welche Systeme reden sollen, welche APIs sie haben und ob es einen fertigen Connector gibt. Oft stellt sich hier schon heraus, dass für einen Teil der Standard reicht und nur ein Sonderfall gebaut werden muss.
Feld-Mapping und Richtung festlegen
Nicht jedes Feld gehört in beide Systeme. Wir legen fest, welche Objekte und Felder in welche Richtung laufen und welches System die Führung hat. Dieser Schritt entscheidet später über die meisten Probleme.
Bauen und gegen Echtdaten testen
Ich baue die Anbindung, mit Dublettencheck, sauberem Mapping und Schutz gegen doppelte Syncs. Getestet wird mit echten Datensätzen aus deinem System, nicht nur mit Beispielen.
Live, überwacht und dokumentiert
Die Schnittstelle geht in Betrieb, mit Fehler-Benachrichtigung und Wiederholung bei API-Limits. Du bekommst eine kurze Doku, welche Daten wohin laufen, damit dein Team es nachvollziehen kann.
Woran du eine gute Schnittstelle erkennst
- Sie schreibt nur die Felder, die wirklich in beide Systeme gehören, und hat eine klare führende Seite bei Konflikten.
- Vor jedem Schreiben prüft sie auf Dubletten, statt blind neue Datensätze anzulegen.
- Bei einem API-Limit oder Ausfall wiederholt sie den Lauf, statt still Daten zu verlieren.
- Es gibt eine Fehler-Benachrichtigung und eine kurze Doku, damit dein Team nachvollziehen kann, was wohin läuft.
Das klingt nach Selbstverständlichkeiten, ist aber genau der Teil, der bei schnell zusammengesteckten Anbindungen fehlt. Und es ist der Teil, der später über die Datenqualität in HubSpot entscheidet.
Häufige Fragen zu HubSpot-Schnittstellen
Lass uns dein System an HubSpot anbinden
Erzähl mir kurz, welche Systeme du im Einsatz hast und was zwischen ihnen laufen soll. Im Erstgespräch sage ich dir ehrlich, ob ein fertiger Connector reicht, eine Middleware der Weg ist oder eine eigene Schnittstelle Sinn ergibt.
- Kostenloses Erstgespräch, ca. 15 Minuten
- Klare Einschätzung: nativer Connector, Middleware oder eigene Schnittstelle
- Ehrlicher Blick auf Aufwand und Datenmenge, bevor etwas gebaut wird