HubSpot CRM-API: Validierungsregeln ab 2026-09 Pflicht

HubSpot setzt ab dem 8. September 2026 mit der API-Version /2026-09/ erstmals durch, dass Admin-konfigurierte Validierungsregeln auch für Schreibzugriffe über die CRM-API gelten. Wer Kontakte, Deals oder Tickets per API anlegt oder aktualisiert, bekommt ab dieser Version einen Fehler zurück, sobald ein Call gegen Pflichtfelder, eindeutige Werte oder Formatvorgaben verstößt, die im Account definiert sind. Für bestehende Integrationen ist das ein Breaking Change im wörtlichen Sinn: Was heute stillschweigend gespeichert wird, kann ab dem Versionswechsel abgelehnt werden.

Was sich mit der API-Version 2026-09 ändert

Mit der neuen Version erzwingt HubSpot, dass Admin-konfigurierte Validierungsregeln bei jedem Create- und Update-Call auf Kontakte, Unternehmen, Deals, Tickets und benutzerdefinierte Objekte gelten. Details dazu veröffentlicht HubSpot im offiziellen Changelog.

Bisher griffen viele dieser Regeln vor allem bei Eingaben über die Benutzeroberfläche: Pflichtfelder, eindeutige Werte, Formatvorgaben für Telefonnummern oder E-Mail-Adressen, erlaubte Werte in Dropdown-Feldern. Wer Daten über die API geschrieben hat, etwa mit Zapier, Make, einem Custom-Skript oder einer Middleware zwischen ERP und CRM, konnte diese Regeln in der Vergangenheit teilweise umgehen. Ab 2026-09 schließt sich diese Lücke.

Warum HubSpot Validierungsregeln jetzt auf API-Ebene durchsetzt

Der Schritt passt in eine Reihe von Änderungen, mit denen HubSpot Datenqualität zunehmend zur Pflicht statt zur Kür macht. Inkonsistente Daten, die über API-Integrationen ins System gelangen, erzeugen im Tagesgeschäft klassische Folgeprobleme: fehlerhafte Segmentierung, kaputte Automatisierungen, Reporting, das nicht mit der Realität übereinstimmt. Für HubSpot als Plattform ist das strukturell unbefriedigend, weil Admins Regeln definieren, die durch API-Writes de facto ausgehebelt werden konnten.

Mit der Versionierung der CRM-API kann HubSpot solche Breaking Changes kontrolliert einführen. Wer eine Integration betreibt, bestimmt selbst, wann er auf eine neue API-Version wechselt, ältere Versionen bleiben zunächst nutzbar. Ein ähnliches Muster war bereits beim Sunset der Pipelines API V1 zu beobachten: Erst gilt die neue Logik nur für Integrationen, die sie aktiv anfordern, später wird sie zur Pflicht für alle.

Wer ist von der neuen Regel betroffen?

Betroffen ist jede Integration, die CRM-Datensätze über die API anlegt oder aktualisiert und dabei auf eine Objektdefinition trifft, für die im Account Validierungsregeln konfiguriert sind. Das betrifft typischerweise:

• Marketing-Automation-Tools und Formulare von Drittanbietern, die Leads direkt per API ins CRM schreiben
• Middleware zwischen ERP, Billing-Systemen oder Produktdatenbanken und HubSpot
• Custom-Integrationen und Private Apps, die im Rahmen von Migrationsprojekten oder Datenabgleichen Datensätze schreiben
• No-Code-Tools wie Zapier oder Make, sofern sie Write-Operationen auf validierte Felder ausführen

Nicht betroffen sind reine Lesezugriffe. Relevant wird die Änderung erst, wenn eine Integration explizit auf die API-Version 2026-09 oder eine spätere Version umgestellt wird, entweder manuell durch den Entwickler oder durch ein Update der verwendeten Library beziehungsweise des SDK.

Was Unternehmen jetzt konkret prüfen sollten

Wer HubSpot über mehrere Integrationen pflegt, sollte vor dem Versionswechsel folgende Punkte klären:

• Welche Properties im Account sind als Pflichtfeld, eindeutiger Wert oder mit Format- beziehungsweise Werteliste konfiguriert? Diese Übersicht liegt in den Objekteinstellungen der jeweiligen Objekte.
• Schreiben bestehende Integrationen aktuell Werte, die gegen diese Regeln verstoßen würden, etwa leere Pflichtfelder, doppelte eindeutige Kennungen oder Freitext in Feldern mit fester Werteliste?
• Gibt es Fehlerbehandlung in der eigenen Integration für den Fall, dass ein Write-Call künftig mit einem Validierungsfehler abgelehnt wird, statt wie bisher stillschweigend durchzugehen?
• Wer in der Organisation verantwortet die Validierungsregeln im Account, und wer die Integrationen? Häufig sind das unterschiedliche Teams.

Gerade der letzte Punkt ist in der Praxis oft der Knackpunkt. Validierungsregeln werden meist vom CRM-Admin oder RevOps-Team gepflegt, Integrationen oft von IT oder externen Dienstleistern gebaut. Ändert sich eine Regel im Account, ohne dass die Integration informiert wird, bricht der Schreibzugriff ab dem Versionswechsel ohne Vorwarnung. Wer intern unklare Zuständigkeiten für solche Fragen hat, findet dazu eine ausführlichere Einordnung im Artikel zu Data Ownership im CRM.

Was passiert, wenn eine Integration nicht konform ist

Technisch bedeutet die Durchsetzung: Ein Create- oder Update-Call, der gegen eine konfigurierte Regel verstößt, wird von der API mit einem Fehler abgelehnt, statt den Datensatz mit fehlerhaftem oder leerem Wert zu speichern. Für gut gewartete Integrationen mit sauberer Fehlerbehandlung ist das zunächst unkritisch, der Fehler lässt sich loggen und beheben. Für ältere oder wenig gepflegte Integrationen, die Antworten nicht systematisch auswerten, kann das zu stillen Ausfällen führen: Datensätze werden nicht mehr aktualisiert, ohne dass das im Tagesgeschäft sofort auffällt.

Besonders betroffen sind Setups, die über Jahre gewachsen sind und bei denen niemand mehr genau dokumentiert hat, welche Felder tatsächlich wie validiert werden. Ein ähnliches Muster zeigte sich auch bei der Deaktivierung von Legacy Private Apps. Oft liegt das Risiko weniger in der Umstellung selbst als in fehlender Dokumentation darüber, was eine bestehende Integration eigentlich tut.

Einordnung für RevOps und Dateneigentümer

Für RevOps-Teams ist die Änderung vor allem eine Gelegenheit, Validierungsregeln und Integrationslandkarte einmal gemeinsam durchzugehen, statt sie getrennt voneinander zu pflegen. Bei solchen Breaking Changes zeigt sich regelmäßig, dass niemand eine vollständige Übersicht über alle Schreibzugriffe auf das CRM hat, vor allem dort, wo Datensilos zwischen Systemen bestehen. Ein belastbares Datenmodell, das Validierungsregeln, Pflichtfelder und Integrationen zusammen dokumentiert, reduziert dieses Risiko deutlich, wie auch der Beitrag zu Datensilos und Datenmodell in RevOps beschreibt.

Bis zum 8. September 2026 bleibt Zeit, bestehende Integrationen zu testen, bevor der Versionswechsel ansteht. Wer HubSpot produktiv mit mehreren angebundenen Systemen betreibt, sollte diesen Termin im Projektplan für das dritte Quartal 2026 vormerken.

Häufig gestellte Fragen

Ab wann gilt die neue Validierungspflicht?

Die API-Version /2026-09/ erscheint am 8. September 2026. Die Validierungsregeln greifen, sobald eine Integration explizit auf diese oder eine spätere API-Version umgestellt wird.

Müssen wir sofort handeln, wenn wir eine ältere API-Version nutzen?

Nicht sofort. Solange eine Integration auf einer älteren API-Version verbleibt, gilt die neue Durchsetzung zunächst nicht. Spätestens beim nächsten geplanten Update einer Library, eines SDK oder einer Middleware lohnt sich aber ein Check, ob dabei implizit auf 2026-09 gesprungen wird.

Welche Validierungsregeln sind konkret gemeint?

Gemeint sind alle Regeln, die ein Admin im HubSpot-Account für Properties konfiguriert hat, etwa Pflichtfelder, eindeutige Werte, erlaubte Werte aus einer Liste oder Formatvorgaben. Diese Regeln galten bisher primär für die Benutzeroberfläche und werden nun auch bei API-Schreibzugriffen durchgesetzt.

Was ist der Unterschied zu einem normalen API-Fehler?

Ein Validierungsfehler entsteht nicht durch eine falsche Anfrage-Syntax, sondern durch inhaltlich unzulässige Werte, etwa ein leeres Pflichtfeld oder einen bereits vergebenen eindeutigen Wert. Integrationen sollten diesen Fehlertyp gesondert abfangen und nicht wie einen generischen Serverfehler behandeln.