Customer.io unifica el acceso a sus APIs con 2 tipos de claves: públicas para aplicaciones y privadas para servidores

Customer.io anunció el 30 de octubre de 2026 un esquema de acceso a sus APIs con dos tipos de claves, elegidos según dónde se ejecuta el código. El cambio distingue las aplicaciones que usa el cliente de las integraciones que corren en servidores.

La novedad permite revisar cómo llegan los eventos a marketing y quién mantiene cada conexión. La continuidad también importa: el anuncio confirma que las credenciales actuales siguen funcionando. Un equipo comercial puede preparar la transición con su responsable técnico y comprobar el resultado antes de retirar accesos antiguos.

¿Qué diferencia a las claves públicas de las privadas?

Las claves públicas comienzan con pk_ y están destinadas a navegadores y aplicaciones móviles. Permiten identificar personas, enviar eventos y gestionar mensajes dentro de la aplicación. No autorizan la lectura de datos ni el envío directo de mensajes mediante las APIs que requieren una clave privada.

Las privadas comienzan con sk_, se usan en servidores y dan acceso al conjunto de APIs, incluidas operaciones sensibles. Para quien dirige marketing, conviene traducir esa distinción a un inventario operativo: qué sistema captura la actividad y qué proceso puede modificar datos o activar comunicaciones. Son responsabilidades distintas, aunque compartan proveedor.

¿Es obligatorio reemplazar ahora las credenciales existentes?

Customer.io mantiene las credenciales anteriores. Su documentación también conserva un apartado para las claves heredadas. Por eso, actualizar una conexión debe partir de su compatibilidad y de una prueba acordada, sin asumir que el anuncio obliga a sustituir todas las integraciones a la vez.

La lectura práctica es separar proyectos. Una implementación nueva puede evaluar el esquema actual desde el inicio; una conexión en producción necesita primero saber qué biblioteca utiliza y quién puede desplegar un cambio. Mezclar ambas tareas en una actualización general dificulta identificar el origen de un problema si luego faltan eventos o se altera una audiencia.

¿Cómo preparar el cambio sin interrumpir la llegada de datos?

La documentación de gestión de credenciales indica crear una clave nueva, cambiar la integración y revocar la antigua cuando ya no se use. En aplicaciones móviles, advierte que las versiones sin actualizar pueden continuar utilizando el acceso anterior. Ese detalle obliga a coordinar el despliegue con quienes mantienen la aplicación.

Como preparación editorial, proponemos una ficha por conexión: responsable, aplicación de origen, destino, uso de la credencial y prueba que confirma el funcionamiento. El equipo de marketing debería poder ver el resultado de negocio de esa prueba, como la recepción del evento esperado y la pertenencia correcta a una audiencia. Una respuesta técnica satisfactoria por sí sola no demuestra que el recorrido comercial quedó completo.

¿Qué significa para las empresas en Chile y Latinoamérica?

Para una empresa B2B de Chile o Latinoamérica que conecta su producto, su CRM y sus comunicaciones, la oportunidad está en ordenar la responsabilidad de esos traspasos. Una falla de captura puede parecer una baja de demanda si nadie revisa la fuente. El anuncio no acredita aumentos de conversión ni ahorros; esos resultados tendrían que medirse en cada operación.

Análisis de Revenue Hub

Nuestra lectura es que simplificar las credenciales ayuda a entender una integración, pero no reemplaza su gestión. La gerencia necesita saber quién responde cuando una fuente deja de enviar datos. Si además utiliza HubSpot, puede aplicar nuestra guía para detectar una integración que dejó de traer registros y acordar una alerta basada en el volumen esperado. El objetivo es descubrir el silencio antes de que llegue a una revisión comercial.

La recomendación concreta es empezar con una conexión acotada y documentada. Antes del cambio, registrar qué eventos recibe marketing; después, comprobarlos con el mismo criterio y asignar a una persona la aceptación del resultado. No retirar el acceso anterior hasta que el responsable técnico confirme que dejó de utilizarse. Es una propuesta de trabajo, no una exigencia adicional anunciada por el proveedor.

Conviene cerrar la revisión con una conversación entre marketing y tecnología: qué dato activa cada comunicación, cómo se comprueba su llegada y quién decide detener una automatización si algo se desvía. La mejor señal de mejora será poder explicar y mantener el recorrido sin depender de la memoria de quien lo construyó. Esa capacidad merece más atención que la cantidad de claves que se logre eliminar.