HubSpot ha abierto dieciséis nuevas API para el público general y, en la misma versión, ha fijado una fecha límite para todas las anteriores. Esta combinación resulta más útil que cualquiera de las dos por separado. Durante años, la respuesta sincera a la pregunta "¿por qué esa integración requiere código personalizado?" era que HubSpot simplemente no exponía el objeto en cuestión, así que alguien creó una solución alternativa, la documentó superficialmente y siguió adelante. El 15 de septiembre, la lista de elementos que aún requieren una solución alternativa se redujo considerablemente, y ahora hay una fecha límite que convierte la eliminación de los antiguos en un proyecto financiado, en lugar de una simple buena intención.
Una de esas fechas límite pasó ayer, lo cual justifica leer el comunicado detenidamente esta semana en lugar del próximo trimestre. No contiene nada que genere problemas, y se trata simplemente de ajustes que se amortizan con la precisión de los informes y la fiabilidad de la integración.
¿Qué novedades lanzó HubSpot para desarrolladores en septiembre de 2026?
La versión Fall Spotlight para desarrolladores se lanzó el 15 de septiembre, un día antes de la inauguración de UNBOUND en Boston, y representa la mayor ampliación de la API de HubSpot en varios años. La plataforma para desarrolladores 2026.09 alcanzó su disponibilidad general como la segunda versión con fecha de lanzamiento definida, con un período de soporte de dieciocho meses que indica con precisión cuánto tiempo se mantendrá la versión en la que se desarrolla. Esta previsibilidad supone una mejora discreta pero significativa con respecto al versionado numérico, donde el fin del soporte siempre dependía del criterio de cada usuario.
Dieciséis API pasaron a estar disponibles para el público general, y varias de ellas solucionan problemas que los clientes de HubSpot llevaban tiempo intentando resolver. La API de Conversaciones ofrece acceso programático a la bandeja de entrada compartida y al servicio de asistencia. Las API de Listas de Precios y Enlaces de Pago abren Commerce Hub para cuentas profesionales y empresariales, y ahora los enlaces de pago pueden gestionar carritos de compra dinámicos con varios artículos. Una API de Reglas de Canalización cierra lo que HubSpot describió como una brecha de paridad de larga data. La API de Previsiones ofrece acceso de solo lectura a las previsiones enviadas, la API de Equipos permite la creación de equipos y la gestión de miembros desde fuera de la interfaz, la API de Etiquetas de Objetos aplica etiquetas de color a los registros automáticamente, y la API de Plantillas de Correo Electrónico incluye autorización a nivel de usuario. Otras ocho API entraron en beta pública, entre ellas la puntuación de clientes potenciales, los contratos, los formularios de marketing y los flujos de trabajo de automatización.
Además, la experiencia de Aplicaciones conectadas se rediseñó con ajustes organizados por pestañas, propiedad formal de la aplicación que se puede reasignar cuando alguien se va, y un registro de actividad que abarca instalaciones, eventos de permisos y cambios de propiedad. El servidor MCP de HubSpot ahora accede a objetos personalizados, Breeze Assistant puede guiar la configuración del agente en la versión beta pública, y las indicaciones programadas permiten que las tareas recurrentes del asistente se ejecuten según un cronograma.
¿Qué es la deuda técnica de CRM y por qué ayuda establecer una fecha límite publicada?
La deuda técnica de CRM es el costo acumulado de decisiones que tenían sentido en su momento y que nunca se revisaron: código personalizado escrito porque una función estándar aún no existía, integraciones creadas con una versión de API que ya ha quedado obsoleta, flujos de trabajo que nadie ha auditado desde que la persona que los creó se fue, y campos creados para una campaña que terminó hace tres años. Rara vez es urgente y casi nunca es visible para quienes aprueban los presupuestos, razón por la cual se acumula. La deuda no es el código en sí, sino el hecho de que nadie puede afirmar con certeza qué hace el código, por lo que cada nuevo proyecto debe sortearlo en lugar de abordarlo directamente.
Aquí es donde una fecha de finalización publicada demuestra su utilidad. Las solicitudes para modernizar integraciones pierden ante las solicitudes que generan ingresos, siempre, porque las primeras se describen como limpieza y las segundas como crecimiento. Una fecha del proveedor cambia esa conversación en una sola línea. A partir de septiembre de 2027, los endpoints en las rutas /v1/, /v2/ y /v3/ pasan a un estado sin soporte, que HubSpot define como la ausencia de correcciones de errores, mejoras de confiabilidad o actualizaciones de seguridad. Este último punto es el que obtiene la aprobación del presupuesto. La versión 4 se ejecuta en su propio cronograma anterior y deja de tener soporte el 30 de marzo de 2027, y las aplicaciones creadas con el marco Projects 2025.2 o anterior deben alcanzar la versión 2026.09 para marzo de 2027. La guía de HubSpot es migrar directamente al versionado basado en fechas en lugar de pasar por las versiones numeradas.
Leído en ese orden, este es un plan de doce meses con dos etapas intermedias, lo que ofrece un margen de planificación considerablemente mayor que el que ofrecen la mayoría de los cambios de plataforma. Dos de las fechas límite para las aplicaciones están más próximas. La creación de aplicaciones privadas heredadas se cerró para las nuevas cuentas de HubSpot el 28 de septiembre y para las cuentas existentes el 26 de octubre, por lo que cualquier herramienta interna que alguien planeara implementar de la manera antigua tiene aproximadamente cuatro semanas más. Las aplicaciones públicas en la arquitectura pre-Proyectos, es decir, cualquier cosa creada antes del 23 de junio de 2026, pasaron a un estado sin soporte el 15 de septiembre y corren el riesgo de ser eliminadas del Marketplace a partir de septiembre de 2027 si no han migrado. Sin embargo, para la mayoría de los equipos de ingresos B2B, la lectura práctica es más simple y alentadora: nada se rompe este mes y tienes un año para trabajar en una lista que probablemente ya tenías pensado escribir.
¿Cómo se crea un inventario de integraciones que realmente valga la pena tener?
Un estudio preliminar de CRM es una evaluación breve y estructurada que se realiza antes de definir el alcance de un proyecto, generalmente entre dos y seis semanas antes, para determinar qué elementos existen realmente, en lugar de basarse únicamente en la documentación. Se realiza un inventario de las integraciones, el código personalizado, la automatización, la calidad de los datos y los procesos de negocio que cada uno respalda, y se relaciona cada elemento con el resultado que proporciona y las personas que dependen de él. El resultado es una visión priorizada de qué elementos conservar, cuáles reemplazar y cuáles eliminar, con estimaciones de esfuerzo. Su valor reside en que transforma la percepción vaga de que el sistema se ha vuelto complejo en un conjunto de decisiones con presupuesto definido que un comité directivo puede tomar en una sola reunión.
Aplicado a esta versión, un estudio previo responde a tres preguntas. ¿Cuáles de sus integraciones llaman a puntos finales versionados y cuáles de esas llamadas ahora tienen un equivalente basado en fechas? ¿Cuáles de sus soluciones alternativas personalizadas se reemplazan directamente por una de las dieciséis API nuevas disponibles, de modo que la migración sea una eliminación en lugar de una reescritura? ¿Y qué integraciones nadie en la organización puede explicar, que suele ser la categoría más interesante y, de forma fiable, la que genera ahorros?.
Esa tercera pregunta es la razón para realizar este trabajo independientemente de cualquier plazo. Los equipos que gestionan el inventario correctamente suelen encontrar conexiones que siguen consumiendo licencias y llamadas a la API en nombre de un proceso que dejó de funcionar hace meses, y desactivarlas es una de las pocas tareas técnicas que aparecen en las cifras del mismo trimestre.
¿Qué es la IA en la sombra y cómo influyen las claves de servicio en este panorama?
La IA en la sombra consiste en el uso de herramientas de IA y automatización basada en IA dentro de una organización sin el conocimiento, la aprobación ni la supervisión de las personas responsables de la gobernanza de datos. Generalmente comienza bien: un equipo con un problema real encuentra una herramienta que lo resuelve y la conecta con los sistemas que contienen los datos que necesita. El riesgo no reside en el entusiasmo, sino en la invisibilidad, ya que nadie puede proteger, auditar ni mejorar una conexión cuya existencia desconoce. La respuesta eficaz no es la prohibición, que tiende a ocultar aún más la actividad, sino un camino autorizado, más fácil de usar que el no autorizado, con permisos definidos y visibilidad centralizada desde el principio.
Las claves de servicio, ahora en beta pública, representan precisamente ese tipo de vía autorizada. HubSpot las posiciona como el reemplazo de las aplicaciones privadas heredadas en integraciones ligeras, herramientas internas y, en particular, integraciones con agentes de IA, con configuraciones de seguridad más estrictas y un alcance de permisos adecuado. Las aplicaciones de usuario llegan junto con ellas. Si a esto le sumamos el nuevo registro de actividad de Aplicaciones Conectadas y la propiedad de las aplicaciones con nombre y reasignable, el resultado es una plataforma donde una pequeña integración creada por alguien del departamento de marketing es visible, atribuible y restringida por defecto.
Eso supone una mejora real respecto al acuerdo anterior, donde un token de aplicación privada con amplio acceso podía permanecer en una hoja de cálculo indefinidamente. También encaja perfectamente con la medida anterior de HubSpot de aplicar reglas de validación en el límite de la API, que cubrimos en Agosto. En conjunto, la dirección que se está tomando es clara y positiva: la gobernanza está saliendo de la interfaz y entrando en el lugar donde los datos ingresan realmente al sistema.
Cómo integrar CRM con ERP cuando la interfaz de la API está en constante evolución.
La integración de CRM con ERP funciona mejor mediante una capa intermedia definida que con una red de conexiones punto a punto. Establezca un único sistema de registro para cada objeto, normalmente cuentas y productos en el ERP y oportunidades y actividades en el CRM, y luego transfiera los datos a través de una plataforma de integración que centralice el mapeo, las reglas de transformación y el manejo de errores. Sincronice según los eventos de negocio en lugar de un calendario fijo cuando el volumen lo permita, registre cada registro fallido para que las excepciones sean visibles y gestione las versiones del mapeo junto con el código que lo utiliza. Este patrón tiene un coste ligeramente mayor de desarrollo y un coste de mantenimiento considerablemente menor, ya que un cambio de plataforma afecta a un solo conector en lugar de a quince scripts.
Ese argumento es fácil de plantear en abstracto, pero difícil de financiar en la práctica, razón por la cual una revisión exhaustiva de la API resulta útil. Las organizaciones que utilizan integraciones punto a punto se enfrentan a una migración en cada script que llama a un punto final versionado. Las organizaciones que utilizan una capa intermedia solo modifican el conector una vez. Los clientes del sector manufacturero con CPQ y lógica de cotización entre ambos sistemas lo sienten con mayor intensidad, ya que nadie quiere modificar dos veces el proceso de precios. Si en los próximos doce meses se produce una mejora arquitectónica, esta es la que merece la pena implementar.
¿Cómo se mide el retorno de la modernización mediante la integración?
Mida el retorno de la inversión en CRM con métricas operativas que se anticipen a los ingresos. Las más útiles incluyen la proporción de integraciones que se completan sin intervención manual, el tiempo transcurrido desde la solicitud de un nuevo flujo de datos hasta su activación, el número de registros que requieren corrección manual semanal, el consumo de licencias y API en integraciones que ya no forman parte de un proceso activo, y la proporción de informes que se basan en una única fuente acordada. Cada métrica está disponible en semanas, no en trimestres, se atribuye a un cambio específico y, en conjunto, predicen los resultados de ingresos posteriores. Establezca una línea base antes de comenzar el trabajo, ya que esta línea base es la que permite justificar la mejora ante la junta directiva.
En esta versión en particular, las ventajas son inusualmente fáciles de prever. Cada solución alternativa sustituida por una de las dieciséis nuevas API es código que ya no se mantiene. Cada aplicación privada heredada convertida en una clave de servicio con ámbito definido es una ruta de acceso que finalmente se puede auditar. Cada integración retirada supone un ahorro en gastos de licencia. Y una vez realizado el inventario, el siguiente cambio de plataforma, independientemente del proveedor, se convierte en una evaluación de medio día en lugar de un proyecto.
La perspectiva de Sirocco
Trabajamos con Salesforce, HubSpot y Microsoft Dynamics 365, y este año hemos observado el mismo patrón en las tres plataformas. Salesforce retira las versiones de API según un calendario de lanzamientos publicado. Microsoft adoptó la entrega continua con avisos de servicio fechados. HubSpot ha implementado un sistema de versiones basado en fechas con ventanas de soporte que se pueden consultar fácilmente. Los proveedores están haciendo que sus compromisos de mantenimiento sean claros, lo cual beneficia directamente a los compradores, ya que los compromisos claros permiten planificar una hoja de ruta en lugar de reaccionar ante ella.
Es en este tipo de proyectos donde un socio independiente de CRM demuestra su valía. Al no tener cuotas de licencia en ninguna plataforma, nuestras recomendaciones sobre qué migrar, qué eliminar y qué conservar se basan en el proceso del cliente, no en la hoja de ruta del proveedor. Hemos realizado el mismo análisis de integración en las tres plataformas, lo que nos permite determinar qué hallazgos son específicos de cada plataforma y cuáles reflejan simplemente la evolución de las integraciones en general. Y cuando la respuesta honesta es que una configuración existente está en buen estado y que el plazo solo requiere dos semanas de trabajo intensivo, podemos decirlo sin reservas.
Nuestro consejo para el próximo mes es sencillo pero muy efectivo: dediquen una semana a crear el inventario, aprovechen las soluciones rápidas donde una nueva API reemplace directamente el código personalizado y programen las migraciones restantes a lo largo de los doce meses que tienen disponibles. Los equipos que sigan este método llegarán a 2027 desarrollando sobre una plataforma que comprenden, con una lista mucho más corta de aspectos que nadie puede explicar. Esta es una posición ventajosa, y este lanzamiento es una invitación oportuna para alcanzarla.
Si desea una segunda opinión sobre el inventario o sobre cuál de las dieciséis API recientemente disponibles realmente reemplaza algo que usted mantiene actualmente, programar una consulta con nuestro equipo.
Contáctanos
Si estás intentando averiguar cuáles de tus integraciones de HubSpot siguen utilizando puntos finales con versiones anteriores y cuáles han sido reemplazados directamente por una API recientemente disponible, dinos en qué punto te encuentras y te ayudaremos a elaborar el inventario.
