Inicio Canales y buzones de entrada Cómo instalar el Web Widget de Cloud Chat: público, con datos o en área logada (HMAC)

Cómo instalar el Web Widget de Cloud Chat: público, con datos o en área logada (HMAC)

Última actualización el Sep 01, 2026

Cuándo usar

  • Quieres añadir el chat de Cloud Chat en cualquier página de tu sitio web

  • Quieres pasar datos del contacto automáticamente (nombre, correo electrónico, teléfono, atributos) sin que el cliente tenga que escribir

  • Quieres validar la identidad del usuario (HMAC) para impedir que alguien se haga pasar por otra persona

  • Quieres permitir múltiples conversaciones simultáneas y acceder al historial dentro del widget

  • Quieres restringir el widget a dominios específicos (por ejemplo, solo en producción)


Requisitos previos

  • Estar logueado como administrador en Cloud Chat

  • Acceso al código fuente del sitio donde se instalará el widget

  • Para el Escenario 3 (área logada con HMAC): backend propio para generar el identifier_hash — no puede hacerse en el frontend (exponer la clave secreta)


Sobre este tutorial

Este artículo cubre el ciclo completo de instalación del Web Widget de Cloud Chat. Antes de seguir los pasos de código, debes decidir cuál de los 3 escenarios se ajusta a tu caso de uso — tienen requisitos y complejidad muy distintos.

¿Cuál escenario es el tuyo?

Escenario Cuándo usar ¿Pasa datos del cliente? ¿Necesita HMAC?
1. Widget público (sin datos) Sitio público / landing page / blog. El cliente escribe su nombre y correo al iniciar la conversación. ❌ No ❌ No
2. Widget con datos, fuera de área logada Páginas que ya conocen el contacto pero no requieren autentificación fuerte (ej: enlace único enviado por email/CRM, formulario post-registro). ✅ Sí ❌ No
3. Widget en área logada (con HMAC) Portal del cliente, panel interno, app autenticada. Cualquier escenario donde el usuario debe iniciar sesión para acceder. ✅ Sí ✅ Obligatorio

Si tu caso es el Escenario 3 (área logada), debes configurar HMAC. Sin ello, la conversación no se creará.

El atributo personalizado del contacto debe ser creado previamente — consulta Cómo crear campos personalizados de contactos y conversaciones.


Etapa común para todos los escenarios — Crear la bandeja de entrada del tipo Web Widget

Antes de configurar cualquier escenario, debes crear una bandeja de entrada del tipo Sitio Web en Cloud Chat. El procedimiento es el mismo para los 3 escenarios.

1. Acceder a la pantalla de Bandejas de Entrada

En el panel de Cloud Chat, ve a Configuraciones → Bandejas de Entrada y haz clic en el botón Agregar Bandeja de Entrada (arriba a la derecha).

2. Elegir el canal Website

Selecciona la tarjeta Sitio Web en la cuadrícula de canales disponibles.

3. Configurar el canal del sitio web

Completa los campos:

  • Nombre del sitio — nombre visible para el cliente (ej: "Cloud Humans")

  • Dominio del sitio web — dominio donde correrá el widget (ej: cloudhumans.com)

  • Color del Widget — color principal del botón y encabezado

  • Sé bienvenido — título inicial del widget (ej: "¡Hola!")

  • Mensaje de bienvenida, saludo — mensaje de bienvenida

  • Activar saludo del canal — si quieres enviar un mensaje automático al iniciar la conversación

Haz clic en Crear bandeja de entrada.

4. Agregar agentes

Selecciona los agentes que tendrán acceso a esta bandeja. Como administrador, agregate a ti mismo si quieres ver todas las conversaciones.

Haz clic en Agregar agentes.

5. Configuración del script

En la pantalla final (“¡Tu bandeja está lista!”), Cloud Chat muestra el script básico de instalación del widget. Sin embargo, hay otras opciones de configuración que se pueden usar según tu escenario.

Haz clic en Más configuraciones. En esa sección, verás las tres opciones de scripts disponibles para instalación, que explicaremos a continuación.

Listo. Ahora ve al escenario que se ajusta a tu caso (1, 2 o 3) y sigue las instrucciones específicas de cada uno.


Escenario 1 — Web Widget público (sin pasar datos del cliente)

Usa este en páginas públicas (landing, blog, sitio institucional). El cliente escribe su nombre/correo/teléfono al comenzar.

Cómo instalar

Copia el script de la Etapa Común (Paso 5) justo antes del cierre de la etiqueta </body> en el HTML de la página:

Eso es todo. En este escenario no hace falta nada más que el script base. No llames a setUser(), ni pases identifier_hash. El cliente llena sus propios datos en el formulario inicial del widget.


Escenario 2 — Web Widget pasando datos, fuera de área logada

Úsalo cuando ya conoces el contacto, pero la página no requiere login. Ejemplos:

  • Enlace único enviado por email o WhatsApp con el identifier en la URL

  • Página posterior a registro (el cliente acaba de completar un formulario)

  • Página accedida vía enlace profundo de campaña de CRM

Aquí quieres prellenar nombre, email, teléfono y atributos personalizados sin que el cliente tenga que escribir.

Cómo instalar

⚠️ El primer argumento de setUser(...) es el identifier — debe ser único por usuario (ID interno, UUID del banco, etc). Si dejas el identifier fijo (valor estático, ejemplo copiado o placeholder), Cloud Chat combina todos los accesos como el mismo contacto — fusiona tickets de diferentes personas en una sola conversación y rompe el historial de manera irreversible.

Antes de pasar a producción, confirma con tu equipo de ingeniería que el identifier se llena dinámicamente con el ID real del usuario.

Debes pasar al menos el email o el teléfono — son los identificadores que usa Cloud Chat para hacer el match con el contacto.


Escenario 3 — Web Widget en área logada (con HMAC + opcionalmente múltiples conversaciones)

Úsalo cuando el widget está dentro de una área logada (portal del cliente, panel, app autenticada). Aquí HMAC es obligatorio.

Este escenario también es el único donde tiene sentido habilitar múltiples conversaciones + historial.

3.1 — Cómo funciona HMAC

La validación usa HMAC SHA-256: un código generado a partir del identifier del usuario combinado con una llave secreta (token) de la bandeja de entrada.

La generación del identifier_hash es responsabilidad del cliente. El cálculo debe hacerse en el backend (servidor), nunca en el navegador. Si la clave secreta se filtra en el frontend, la protección deja de ser efectiva. Cloud Humans provee el token para cada bandeja; implementar el cálculo y la entrega del hash al widget corresponde al equipo técnico del cliente.

3.2 — Copiar el token de la bandeja

En Configuraciones → Bandejas de Entrada → (tu bandeja Sitio Web) → Configuración avanzada → Validación de Identidad del Usuario → Copiar.

Este token es secreto — guárdalo solo en el backend, nunca en el frontend.

3.3 — Calcular el identifier_hash en el backend

Cuando el usuario inicia sesión en tu sistema, el backend calcula:

identifier_hash = HMAC_SHA256(token_de_la_bandeja, identifier)

Donde identifier es el ID único del usuario (UUID interno, email corporativo, etc).

Ejemplos en servidor:

// Node.js
const crypto = require('crypto');
const hash = crypto
  .createHmac('sha256', '<token-de-la-bandeja>')
  .update('<identifier>')
  .digest('hex');
# Python
import hashlib, hmac
hash = hmac.new(b'<token-de-la-bandeja>', b'<identifier>', hashlib.sha256).hexdigest()
// PHP
$identifier_hash = hash_hmac('sha256', '<identifier>', '<token-de-la-bandeja>');

3.4 — Enviar el hash al widget usando setUser

<script>
  (function(d,t) {
    var BASE_URL="https://cloudchat2.cloudhumans.com";
    var g=d.createElement(t),s=d.getElementsByTagName(t)[0];
    g.src=BASE_URL+"/packs/js/sdk.js";
    g.defer = true;
    g.async = true;
    s.parentNode.insertBefore(g,s);

    g.onload=function(){
      window.cloudchatSDK.run({
        websiteToken: 'TU_TOKEN_AQUI',
        baseUrl: BASE_URL
      });

      window.addEventListener('cloudchat:ready', function() {
        window.$cloudchat.setUser('<id-usuario>', {
          identifier_hash: '<hash-generado-en-backend>',
          email: '[email protected]',
          name: 'João da Silva',
          phone_number: '+5511999999999'
        });
      });
    }
  })(document,"script");
</script>

3.5 — Forzar validación en la bandeja

En Configuraciones avanzadas, activa la opción "Forzar validación de identidad del usuario" → Habilitado. Desde ese momento, las solicitudes sin un identifier_hash válido serán rechazadas.

Activa el "Forzar validación" solo cuando el backend esté enviando el identifier_hash correcto. Si lo activas antes, todas las conversaciones sin hash serán rechazadas y el chat dejará de funcionar. Primero prueba en una bandeja de prueba.

Buenas prácticas:

  • Usa un identifier estable — nunca cambies el identificador de un usuario existente

  • No expongas el token HMAC en el frontend

  • Genera el hash siempre en el backend y envíalo al cliente solo al inicializar el widget

  • Regenera el identifier_hash cada vez que cargues el widget para un usuario autenticado

3.6 — (Opcional) Activar múltiples conversaciones e historial

Con el HMAC funcionando, puedes activar la función de múltiples conversaciones + historial: el mismo usuario puede mantener varias atenciones abiertas en paralelo y ver el historial de conversaciones ya cerradas dentro del propio widget.

Útil para SaaS, B2B o comercio electrónico con altas tasas de recompra/recontacto.

Cómo funciona para el usuario: el widget mostrará dos pestañas — Conversaciones activas (en curso) y Historial de conversaciones (cerradas, con búsqueda por fecha inicial, final y ID del ticket; carga 5 a la vez).

Videos demostrativos:

Cómo habilitar:

  1. En el panel de Cloud Chat, ve a Bandejas de Entrada → (tu bandeja Sitio Web) → Configuración

  2. Activa la opción Múltiples conversaciones por usuario

  3. Copia el nuevo script que aparece tras la activación — ya viene con user_id y identifier_hash en el formato correcto

  4. Sustituye el script actual en la página por este nuevo

La función de múltiples conversaciones e historial depende de que HMAC esté activo y funcionando. No habilites en widget público (Escenario 1) ni en widget sin área logada (Escenario 2)** — sin validación de identidad, cualquiera puede acceder al historial de otro usuario.


Validación de Dominio (opcional, en todos los escenarios)

Configura los dominios donde puede funcionar el widget — útil para evitar uso fuera de dominios autorizados (sandbox, terceros no autorizados).

En Bandejas de Entrada → (tu bandeja) → Configuración, en la sección Validación de Dominio:

Configuración Comportamiento
Campo vacío Sin restricciones — funciona en cualquier dominio
example.com Permite uso solo en ese dominio
*.example.com Permite uso en todos los subdominios (ej: app.example.com, login.example.com)

Cómo probar

  1. Abre la página con el widget instalado

  2. Verifica que el widget aparece en la esquina de la pantalla

  3. Escenarios 2 y 3: confirma que nombre, email, teléfono y atributos aparecen ya completados sin que el cliente tenga que escribir

  4. Escenarios 2 y 3: prueba con al menos 2 usuarios diferentes — abre el widget con uno y luego con otro, revisa en el panel si aparecen como contactos separados (no fusionados en uno solo). Si aparecen fusionados, el identifier está fijo — corrige antes de pasar a producción

  5. Escenario 3: prueba con un identifier_hash inválido y confirma que el widget rechaza la solicitud cuando “Forzar validación” está habilitado

  6. Escenario 3 con múltiples conversaciones: abre dos tickets en paralelo y confirma que aparecen como conversaciones separadas dentro del widget


Preguntas frecuentes

¿Qué pasa si ya existe una información previa del contacto?

La nueva información enviada vía script sobrescribe los datos antiguos. El dato más reciente prevalece.

¿Y si cometo un error en el nombre de algún campo personalizado?

No se genera ningún error. El campo incorrecto se ignora silenciosamente. Solo se actualizan los campos existentes.

¿Puedo pasar atributos también de la conversación?

Por ahora no. La transmisión de atributos personalizados de la conversación no está habilitada en la versión actual (v0) por limitaciones técnicas. Usa el formulario al inicio de la conversación como alternativa.

¿Qué formatos de texto acepta el widget?

El Widget acepta la mayoría de los formatos de Markdown:

  • Negrita / Tachado / Cursiva

  • Bloques de código

  • Enlaces

  • Imágenes

  • Puntos en lista

¿Puedo usar HMAC sin activar conversaciones múltiples?

Sí. HMAC es una capa de seguridad independiente — puedes activar solo HMAC (Escenario 3, pasos 3.1 a 3.5) sin activar múltiples conversaciones (paso 3.6). Lo contrario no es recomendable.

¿Puedo usar esto también en aplicaciones móviles?

Sí, mediante WebView. Consulta Cómo integrar el Web Widget en apps móviles.


Consideraciones