Cambio disruptivo: HubSpot aplicará la validación de escrituras del CRM por API desde la versión 2026-09

HubSpot activa el 8 de septiembre de 2026 un cambio disruptivo en su API: a partir de la versión /2026-09/, las reglas de validación configuradas por los administradores del portal se aplicarán a todas las rutas de escritura del CRM, no solo a las acciones hechas desde la interfaz. Si tu integración crea o actualiza registros, empezará a recibir errores 400 donde antes pasaba sin objeción.

HubSpot lo anunció el 11 de agosto en su changelog para desarrolladores y lo clasifica explícitamente como breaking change. Su argumento: evitar que las apps dejen los datos en estados que contradicen las reglas que el propio cliente definió.

¿Qué reglas empieza a validar HubSpot por API?

Son tres comportamientos:

• Propiedades requeridas condicionales. Si un administrador configuró que una propiedad sea obligatoria cuando otra toma cierto valor, por ejemplo que close_date sea requerida cuando dealstage es closedwon, la API devolverá un error de validación si falta ese dato. Antes esas reglas eran solo de interfaz y la API las ignoraba.
• Configuración de creación de registros. Si en Configuración, Objetos, Crear registro se marcaron propiedades o asociaciones como obligatorias al crear, la API las exigirá en las llamadas POST.
• Permiso de editar asociaciones. Si tu app usa OAuth a nivel de usuario y el usuario que la instaló no tiene el permiso de editar asociaciones, las llamadas que creen, actualicen o eliminen asociaciones devolverán error. Esto no afecta a los tokens de app a nivel de portal.

Un matiz que evita el pánico: estos comportamientos solo aplican cuando un administrador configuró activamente esas reglas en el portal. Si el portal no tiene reglas condicionales, requisitos de creación ni restricciones de permisos de asociación, no hay cambio de comportamiento.

¿Qué errores vas a ver y cómo se manejan?

Las escrituras que violen una regla devuelven 400 Bad Request con códigos identificables, entre ellos MISSING_CONDITIONAL_REQUIRED_PROPERTY, MISSING_REQUIRED_PROPERTY y el mensaje de permiso de edición de asociaciones faltante.

HubSpot es claro en un punto que suele confundir a los equipos técnicos: estos errores no indican necesariamente una falla de la lógica de tu integración, sino que la configuración del portal exige algo que la solicitud no incluyó. La recomendación es leer el mensaje, verificar la configuración del portal, corregir la entrada y reintentar. Nunca reintentar la misma solicitud sin cambios.

¿Cómo prepararse antes del 8 de septiembre?

La guía oficial de HubSpot plantea cinco pasos:

• Revisar la cuenta donde escribe la app: propiedades con reglas condicionales, campos obligatorios en Crear registro y permisos del usuario instalador.
• Consultar las definiciones actuales de propiedades vía GET /crm/{version}/properties/{objectType} para identificar campos obligatorios antes de escribir.
• Asegurar que las llamadas de escritura incluyan todas las propiedades condicionalmente requeridas cuando la propiedad que las gatilla tiene valor.
• Asegurar que los POST de creación incluyan las propiedades y asociaciones marcadas como obligatorias.
• Si la app usa OAuth a nivel de usuario, confirmar que el usuario instalador tenga habilitado el permiso de editar asociaciones, o retirar la escritura de asociaciones del alcance de la app.

Además: la API de fechas se vuelve más permisiva

En el mismo cambio, HubSpot mejora el manejo de propiedades de fecha y hora. Entradas válidas que antes se rechazaban con errores como INVALID_DATE ahora se normalizan y devuelven una respuesta exitosa con un nuevo arreglo warnings que describe la normalización aplicada. Si tu integración espera una forma específica del mensaje de error, conviene actualizarla.

Análisis de Revenue Hub

Este cambio se lee como una nota técnica, pero es una decisión de gobierno de datos con impacto comercial directo. Durante años, la API fue la puerta trasera por la que entraban al CRM registros que la interfaz habría rechazado: negocios sin fecha de cierre, contactos sin propietario, asociaciones creadas por integraciones que nadie auditó. Ese es exactamente el dato sucio que después rompe el forecast y hace que los equipos desconfíen del reporte.

Para las empresas en Chile y Latinoamérica que operan HubSpot con integraciones de facturación, ERP, formularios propios o conectores de terceros, el riesgo real de esta semana no es el cambio en sí, es no saber quién escribe en el CRM. La mayoría de los portales acumularon integraciones a lo largo de años y nadie mantiene el inventario. El 8 de septiembre esa deuda se vuelve visible en forma de errores 400.

La acción concreta para los próximos días es corta: listar las apps con permiso de escritura, identificar cuáles usan OAuth de usuario, revisar las reglas condicionales que el equipo de operaciones configuró en el último año y probar en un portal de desarrollo antes de subir la versión de API. Si nunca se hizo ese inventario, este cambio es la excusa. Es el mismo trabajo que recomendamos en una auditoría de HubSpot, y lo tratamos con más detalle en nuestra cobertura de HubSpot.