Custom APIs und Middleware für HubSpot: Wann sich Eigenentwicklung lohnt
Wann reichen Standard-Integrationen für HubSpot und wann braucht es eine eigene Schnittstelle oder Middleware? Konkrete Signale, was eine Middleware leistet und worauf du beim Ansprechpartner achten solltest.
Custom APIs und Middleware für HubSpot: Wann sich Eigenentwicklung lohnt
Eine Frage höre ich in Erstgesprächen fast immer in irgendeiner Form: "Wir wollen HubSpot mit System X verbinden. Reicht dafür eine fertige Integration, oder müssen wir das programmieren lassen?" Dahinter steckt oft eine zweite, unausgesprochene Frage: An wen wendet man sich dafür überhaupt?
Beide Fragen lassen sich beantworten, aber nicht pauschal. Ob du eine eigene Schnittstelle brauchst, hängt davon ab, was zwischen den Systemen passieren soll. Und der richtige Ansprechpartner hängt davon ab, wie tief die Eigenentwicklung am Ende geht. Ich versuche hier beides zu sortieren, so wie ich es in Projekten durchgehe.
Was du mit Standard-Mitteln schon abdeckst
Bevor jemand über eigene Entwicklung nachdenkt, lohnt der Blick auf das, was ohne Code oder mit sehr wenig Code geht. HubSpot hat einen Marketplace mit fertigen Integrationen für die gängigen Tools: Mailchimp, Slack, Gmail, viele Buchhaltungs- und Kalender-Apps. Wenn deine Anforderung lautet "Kontakte aus Tool A sollen in HubSpot landen" und beide Seiten eine fertige Verbindung anbieten, brauchst du keine Entwicklung. Du brauchst eine Stunde zum Einrichten.
Die nächste Stufe sind Automationsplattformen wie n8n, Make oder Zapier. Damit verbindest du HubSpot mit hunderten anderen Diensten, ohne selbst eine API-Anbindung zu programmieren. Ein Formular füllt einen Kontakt, ein neuer Deal löst eine Slack-Nachricht aus, ein nächtlicher Lauf gleicht zwei Listen ab. Für einen großen Teil der Anforderungen, die im Alltag auftauchen, ist das die richtige Antwort. Welches dieser Tools wann passt, habe ich im Vergleich von n8n, Zapier und Make ausführlicher beschrieben.
Mein Punkt: Custom-Entwicklung ist nicht der Standardweg, sondern der Weg für die Fälle, in denen die Standardwege nicht mehr tragen. Wer mit einem komplexen Eigenbau anfängt, obwohl eine fertige Integration genügt, zahlt für Komplexität, die er nicht braucht.
Die Signale, an denen du eine eigene Schnittstelle erkennst
Es gibt ein paar wiederkehrende Muster, bei denen ich im Gespräch ziemlich schnell sage: Hier kommst du um eine eigene Schnittstelle nicht herum.
Das erste ist Logik, die kein fertiger Connector abbildet. Ein Beispiel aus der Praxis: Bevor ein Auftrag aus dem ERP zu einem Deal in HubSpot wird, müssen mehrere Positionen zusammengerechnet, Rabatte berücksichtigt und ein Status aus zwei Feldern abgeleitet werden. Ein Standard-Connector kennt diese Regeln nicht. Er kann Feld auf Feld mappen, aber nicht rechnen und entscheiden.
Das zweite ist eine Datenquelle ohne fertige Anbindung. Viele Branchensysteme, Altsysteme oder selbst gebaute Datenbanken haben keinen Eintrag im HubSpot-Marketplace und keinen Connector bei den Automationsplattformen. Wenn die einzige Tür eine rohe API oder eine Datenbankverbindung ist, schreibt jemand den Code, der durch diese Tür geht.
Das dritte ist Datenvolumen und Stabilität. Ein gelegentlicher Abgleich von ein paar Kontakten ist unkritisch. Sobald aber zehntausende Datensätze regelmäßig wandern, werden Themen wichtig, die in einem fertigen Connector unsichtbar bleiben: die Rate Limits der HubSpot-API, das Verhalten bei einem Abbruch mitten im Lauf, das Vermeiden von Doppelanlagen. Mehr dazu, was im HubSpot-CRM per API überhaupt geht und wo die Limits liegen, steht in meinem Artikel zum API-Zugang im kostenlosen HubSpot.
Wenn keiner dieser Punkte zutrifft, brauchst du wahrscheinlich keine Eigenentwicklung. Wenn einer klar zutrifft, lohnt sich das Gespräch darüber.
Was eine Middleware konkret tut
Der Begriff Middleware klingt abstrakter, als die Sache ist. Gemeint ist eine kleine eigene Anwendung, die zwischen HubSpot und dem anderen System sitzt und die Arbeit macht, die keine der beiden Seiten übernimmt.
Sie holt Daten aus der einen Quelle, bringt sie in die Form, die die andere Seite erwartet, und schreibt sie dort hinein. Dazwischen passiert das, worauf es ankommt: Felder werden umgerechnet, Sonderfälle abgefangen, Dubletten erkannt, eine klare Quelle der Wahrheit durchgesetzt, wenn beide Seiten dasselbe Feld kennen. Die Middleware merkt sich außerdem, was sie schon übertragen hat, damit ein zweiter Lauf nicht alles doppelt anlegt.
Genau hier entscheidet sich, ob eine Integration im Betrieb ruhig bleibt oder ständig Ärger macht. Eine Schnittstelle, die nur den Idealfall kennt, läuft am Tag der Einrichtung. Eine, die mit fehlenden Feldern, einem kurzen Ausfall des Zielsystems und einem überschrittenen Rate Limit umgehen kann, läuft auch in einem halben Jahr noch. Der Unterschied steckt selten in der Hauptfunktion und fast immer in der Behandlung der Ausnahmen.
Worauf du beim Ansprechpartner achten solltest
Damit zur zweiten Frage: Wer baut so etwas, und woran erkennst du, dass du beim Richtigen gelandet bist?
Es gibt grob drei Wege. Eine große Integrationsagentur bringt Prozess und Kapazität mit, ist bei kleineren Anbindungen aber oft schwerfällig und teuer. Ein einzelner Entwickler oder Freelancer ist nah am Code und flexibel, fällt aber als Single Point of Failure aus, wenn er ausgebucht ist oder das Projekt verlässt. Ein kleiner spezialisierter Dienstleister liegt dazwischen und ist für die meisten B2B-Fälle die praktischste Wahl, sofern HubSpot und API-Arbeit wirklich zum Kerngeschäft gehören und nicht nur eine von vielen Disziplinen sind.
Wichtiger als die Kategorie ist, worauf du achtest. Frag nach dem Umgang mit den Themen, die ich oben beschrieben habe: Wie geht die Lösung mit Rate Limits um? Was passiert, wenn ein Lauf mittendrin abbricht? Wie wird verhindert, dass Kontakte doppelt entstehen? Wer auf diese Fragen konkret antwortet statt allgemein, hat solche Schnittstellen schon gebaut.
Achte außerdem darauf, wem die Lösung am Ende gehört. Eine gute Anbindung ist dokumentiert, läuft auf eurer Infrastruktur oder einer, auf die ihr Zugriff habt, und lässt sich auch von jemand anderem weiterpflegen. Eine Schnittstelle, die nur ihr Erbauer versteht und die in einem Account liegt, an den ihr nicht herankommt, ist ein Risiko, egal wie gut sie heute funktioniert.
Und ein letzter Punkt, der oft untergeht: Ein ehrlicher Ansprechpartner sagt dir auch, wenn du gar keine Eigenentwicklung brauchst. Wer auf jede Anfrage mit "klar, das programmieren wir" antwortet, verdient an Komplexität. Mir ist es lieber, eine fertige Integration oder einen n8n-Workflow vorzuschlagen, wenn der den Job tut, und die Eigenentwicklung für die Fälle aufzuheben, in denen sie wirklich nötig ist.
Wie ich das angehe
Bei Pipewave baue ich genau diese Schnittstellen: von der Anbindung einer einzelnen API bis zur Middleware, die HubSpot mit ERP, Buchhaltung oder einer eigenen Anwendung verbindet. Ich fange aber nicht mit dem Code an, sondern mit der Frage, ob es ihn überhaupt braucht. Wie eine solche Anbindung in einem konkreten Projekt aussieht, zeige ich in der Case Study zu n8n-HubSpot-Workflows.
Wenn du gerade vor genau dieser Entscheidung stehst, schau dir an, wie ich CRM-Integration und eigene Schnittstellen umsetze, oder schreib mir über das Kontaktformular. Beschreib kurz, welche Systeme du verbinden willst und was dabei passieren soll. Ich sage dir ehrlich, ob das mit Standard-Mitteln geht oder ob sich hier eine eigene Schnittstelle lohnt.
Geschrieben von Joshua Kresse. Ich baue bei Pipewave HubSpot-Integrationen und eigene Schnittstellen für B2B-Unternehmen.