La campaña ha salido. Ahora llega la pregunta que nadie puede responder sin exportar algo: ¿quién ha recibido el mensaje? El estado de cada envío existe, pero vive en el panel del proveedor. El webhook de retorno trae ese estado de vuelta al registro del cliente, donde sirve para la siguiente decisión.
Cómo funciona el webhook
Cuando cambia el estado de un mensaje, el proveedor hace una llamada HTTP a una URL que tú le has indicado. El cuerpo de la llamada trae el evento: el identificador del mensaje, el nuevo estado y otros datos que varían de un proveedor a otro.
Por tu parte, alguien tiene que recibir esa llamada, responder rápido y guardar el estado. Responder rápido importa: si la respuesta tarda, el proveedor considera que ha fallado y lo intenta de nuevo.
En DeepMiner, la recepción solo comprueba la URL y deja el evento en una cola, respondiendo a continuación. El procesamiento ocurre justo después, fuera de la llamada del proveedor.
Encontrar el registro correcto
El evento dice qué mensaje ha cambiado de estado. Tú necesitas saber qué cliente recibió ese mensaje. Hay dos formas habituales de hacer esa conexión.
La primera es mandar una referencia del registro junto con el mensaje, que el proveedor devuelve en el evento. La segunda es guardar el identificador que el proveedor devolvió en el envío y buscarlo cuando llega el evento.
DeepMiner usa las dos. Busca primero la referencia del registro y, si no la hay, el identificador del mensaje guardado en el envío. La búsqueda queda limitada a los índices del partner vinculados a ese proveedor. Cuando nada coincide, el evento queda registrado como sin correspondencia.
Qué guardar en el registro
El estado solo ya ayuda, pero el registro es más útil con un poco de contexto. Para cada canal, DeepMiner guarda el estado, la fecha de la última actualización y los campos del evento definidos para ese tipo de proveedor. El evento completo entra en el historial del registro, que guarda los últimos eventos de todos los proveedores.
Como cada canal guarda sus propios campos, el mismo cliente puede tener el estado del SMS y el del RCS uno junto al otro, visibles en la lista de registros del índice.
Duplicados y seguridad de la URL
Los eventos repetidos ocurren, y guardar dos veces desordena el historial. DeepMiner identifica el cuerpo de cada evento ya aplicado y marca la repetición como duplicada. La marca solo se guarda cuando la actualización ha salido bien, de modo que un fallo a mitad de camino deja que el evento se aplique en el siguiente intento.
La URL es la credencial del webhook. Quien la conoce puede enviar eventos. Por eso, en DeepMiner cada proveedor tiene una URL propia con un token aleatorio, que se muestra una sola vez. Solo se guarda una firma del token. Si la URL se filtra, Regenerar token crea una nueva y la anterior deja de funcionar. Antes de aplicar cualquier evento, DeepMiner vuelve a comprobar que el proveedor sigue activo y que el token sigue siendo el mismo.
El log de cada evento
Cuando un estado no aparece, la primera pregunta es si el evento llegó. El log de webhooks lo responde: cada evento aparece como procesado, duplicado, sin correspondencia o con fallo, con el payload para poder revisarlo. El detalle del registro muestra los eventos de los proveedores de ese cliente.
Qué cambia después
Con el retorno en el registro, el seguimiento de la campaña queda en tres lugares. La ejecución muestra el total de registros, los enviados y los fallos. La lista de registros del índice muestra el estado de cada canal por cliente, y el detalle del registro guarda los eventos. El log de webhooks muestra lo que llegó del proveedor y lo que no encontró registro.
¿Quieres ver un evento de retorno llegando al registro? Solicita una demostración.
Preguntas frecuentes
¿Qué es un webhook de retorno?
Es una URL a la que llama el proveedor de mensajería para avisar de que ha cambiado el estado de un envío. El sistema que la recibe guarda ese estado donde resulte útil.
¿Por qué llega dos veces el mismo evento?
Los proveedores suelen reenviar cuando no reciben la confirmación a tiempo. Quien recibe debe reconocer el evento repetido y no aplicar de nuevo la misma actualización.
¿Cómo sabe DeepMiner a qué registro pertenece el evento?
Por la referencia del registro enviada junto con el mensaje o por el identificador del mensaje que el proveedor devolvió en el envío. Solo se consideran los índices vinculados a ese proveedor.