Cambio bloqueante: HubSpot aplicará las reglas del administrador a todas las escrituras por API del CRM

HubSpot anunció el 11 de agosto de 2026 un cambio bloqueante en su API del CRM. A partir del 8 de septiembre de 2026, con el lanzamiento de la versión /2026-09/, las reglas de validación que configura un administrador del portal dejarán de aplicar solo en la interfaz y pasarán a aplicar también en todas las rutas de escritura por API.

El propio changelog de HubSpot lo explica así: el cambio existe para evitar que una aplicación haga modificaciones que violen las expectativas del usuario de HubSpot y dejen los datos en estados extraños que contradicen sus propias reglas. Dicho de otro modo, la API deja de ser una puerta trasera al gobierno de datos del portal.

¿Qué tres comportamientos se empiezan a validar?

1. Propiedades condicionalmente obligatorias. Si un administrador configuró una regla que hace obligatoria una propiedad cuando otra tiene un valor específico, por ejemplo que close_date sea obligatoria cuando dealstage pasa a closedwon, la API devolverá un error de validación 400 si esa propiedad falta en la escritura. Antes estas reglas eran solo de interfaz y la API las ignoraba. El código de error es MISSING_CONDITIONAL_REQUIRED_PROPERTY.

2. Ajustes de creación de registros. Si un administrador marcó propiedades o asociaciones como obligatorias al momento de crear un registro en Configuración, Objetos, tipo de objeto, Crear registro, la API aplicará esos requisitos en las llamadas POST. El código de error es MISSING_REQUIRED_PROPERTY.

3. Permiso Editar asociaciones. Si tu aplicación usa OAuth a nivel de usuario y el usuario que la instaló no tiene el permiso Editar asociaciones, con el scope CRM_ASSOCIATIONS_WRITE_ACCESS, las llamadas que creen, actualicen o eliminen asociaciones devolverán error. Esto no afecta a los tokens de aplicación a nivel de portal.

HubSpot aclara un punto clave: estos comportamientos solo aplican cuando un administrador configuró activamente esas reglas en el portal. Si no existen reglas de propiedades condicionales, requisitos de creación de registros ni restricciones de permisos de asociación, no hay cambio de comportamiento.

¿Cómo se prepara un equipo en Chile y Latinoamérica?

HubSpot publicó una lista de verificación concreta. Primero, revisar la cuenta donde escribe la aplicación: Configuración, Propiedades para reglas condicionales; Configuración, Objetos, Crear registro para campos obligatorios; y Configuración, Usuarios y equipos para confirmar permisos del usuario instalador.

Segundo, consultar las definiciones actuales de propiedades vía GET /crm/{version}/properties/{objectType} para identificar campos obligatorios antes de las llamadas de escritura. Tercero, asegurar que las escrituras incluyan todas las propiedades condicionalmente obligatorias cuando la propiedad que las controla tiene valor. Cuarto, verificar que los POST de creación incluyan todo lo marcado como obligatorio. Y quinto, si la app usa OAuth a nivel de usuario, confirmar que el instalador tenga habilitado Editar asociaciones o quitar las escrituras de asociaciones del alcance de la app.

¿Qué hacer cuando llegue un error 400?

HubSpot recomienda tratar estos errores como una señal de configuración del portal, no necesariamente como una falla de la lógica de la integración. Cada violación devuelve un mensaje específico que identifica la regla incumplida. La recomendación es leer el mensaje, volver a verificar la configuración del portal porque un administrador pudo haber agregado o cambiado la regla después de configurar la integración, reintentar con la entrada corregida y nunca reintentar la misma petición sin cambios.

Para equipos de RevOps en Chile y Latinoamérica que operan integraciones propias o de terceros, ese último punto es el más importante: un reintento ciego contra una regla de validación solo genera ruido en los logs y consumo de límites de tasa.

¿Qué más cambia en la misma versión?

La API del CRM también pasa a manejar de forma más permisiva las propiedades de tipo fecha y hora. Entradas válidas como valores de fecha fuera de medianoche, cadenas ISO 8601 o marcas de tiempo en segundos epoch, que antes podían ser rechazadas con errores como INVALID_DATE, ahora se normalizan y la respuesta incluye un nuevo arreglo warnings que describe la normalización aplicada. Los mensajes de error para fallas reales también mejoran: ahora incluyen la entrada original, la interpretación que hizo el sistema y qué restricción se violó.

Si tu integración esperaba una forma específica del mensaje de error, hay que actualizarla a esta nueva estructura.

Análisis de Revenue Hub

Este cambio es más estratégico de lo que parece por su envoltorio técnico. Durante años, la API de HubSpot fue el camino para saltarse las reglas que el equipo de operaciones había puesto en la interfaz: el formulario exigía close date, pero la integración de facturación creaba el negocio sin ella. El resultado eran portales con dos verdades, una para quien trabajaba en la UI y otra para lo que entraba por integración. Ese doble estándar se acaba el 8 de septiembre.

Para un líder comercial la pregunta no es técnica, es de gobierno: ¿cuántos de los datos que hoy alimentan tus reportes de pipeline entraron por una vía que ignoraba tus propias reglas? Si la respuesta es incómoda, este cambio te va a hacer un favor a mediano plazo y te va a costar unas semanas de errores 400 en el corto. Vale la pena pedirle al equipo un inventario de integraciones que escriben en el CRM antes de la fecha, no después.

La recomendación práctica: no actualices la versión de la API a 2026-09 hasta haber auditado propiedades condicionales, requisitos de creación y permisos del usuario instalador en cada portal. El versionado por fecha de HubSpot te permite quedarte en una versión anterior mientras ordenas la casa. Puedes seguir el resto de la cobertura de la plataforma en noticias de HubSpot y las guías operativas en el blog de Revenue Hub.