¿Qué tipos de eventos pueden disparar webhooks en Dailybot?

Dailybot soporta webhooks para check-in completado, reporte de agente recibido, bloqueante detectado, umbral de ánimo cruzado, workflow disparado, kudos enviado y formulario enviado. Cada tipo de evento tiene una estructura de payload distinta documentada en la referencia de webhooks.

¿Cómo autentica Dailybot las entregas de webhooks?

Cada endpoint de webhook recibe un secreto de firma al registrarse. Dailybot incluye una firma HMAC-SHA256 en el encabezado X-Dailybot-Signature de cada entrega. Los consumidores deben verificar la firma contra el payload usando el secreto compartido antes de procesar.

¿Cuál es la política de reintentos de Dailybot para entregas de webhook fallidas?

Dailybot reintenta entregas fallidas (respuestas no-2xx o timeouts) hasta 5 veces con backoff exponencial: 30 segundos, 2 minutos, 10 minutos, 1 hora y 6 horas. Después de agotar todos los reintentos, la entrega se marca como fallida en los logs de webhook.

Referencia de webhooks y eventos - Academy

Los webhooks te permiten enviar eventos de Dailybot a tus propios sistemas en tiempo real. En lugar de hacer polling a la API, registra una URL y Dailybot envía un POST HTTP con un payload estructurado cada vez que se dispara un evento relevante. Esta referencia cubre cada tipo de evento, el formato de payload, la autenticación, el comportamiento de reintentos e integraciones prácticas de ejemplo.

Registrando un endpoint de webhook

Desde el dashboard de Dailybot, ve a Configuración y luego Webhooks. Haz clic en “Agregar endpoint” y proporciona:

URL — El endpoint HTTPS que recibirá las solicitudes POST. HTTP no es aceptado en producción.
Eventos — Selecciona qué tipos de eventos debe recibir este endpoint. Puedes suscribirte a todos los eventos o elegir específicos.
Secreto — Dailybot genera un secreto de firma para el endpoint. Guárdalo de forma segura — lo usarás para verificar las entregas entrantes.

Una vez guardado, el endpoint está activo de inmediato. Puedes probarlo disparando un evento de muestra desde la página de configuración de webhooks.

Tipos de eventos

check_in.completed

Se dispara cuando un miembro del equipo termina de responder un check-in.

Campos clave del payload: check_in_id, user_id, user_name, team_id, responses (array de pares pregunta/respuesta), completed_at (timestamp ISO 8601).

agent_report.received

Se dispara cuando un agente de código envía un reporte de progreso.

Campos clave del payload: agent_id, agent_type (ej., “cursor”, “claude-code”), workspace_id, report_body, metadata (modelo, rama, repositorio), received_at.

blocker.detected

Se dispara cuando una respuesta de check-in coincide con las reglas de detección de bloqueantes.

Campos clave del payload: check_in_id, user_id, user_name, matched_keywords (array), original_response, follow_up_responses (si los seguimientos condicionales están configurados), detected_at.

mood.threshold_crossed

Se dispara cuando el puntaje de ánimo de un equipo o individuo cruza un umbral configurado.

Campos clave del payload: team_id, user_id (null para nivel de equipo), current_score, threshold, direction (“above” o “below”), period, crossed_at.

workflow.triggered

Se dispara cuando se activa una regla de workflow personalizado.

Campos clave del payload: workflow_id, workflow_name, trigger_type, trigger_data, actions_executed (array), triggered_at.

kudos.sent

Se dispara cuando un miembro del equipo envía kudos a un colega.

Campos clave del payload: sender_id, sender_name, recipient_id, recipient_name, message, value (si los valores del equipo están configurados), sent_at.

form.submitted

Se dispara cuando se completa el envío de un formulario.

Campos clave del payload: form_id, form_name, submitter_id, submitter_name, responses (array de pares campo/valor), submitted_at.

Estructura del payload

Toda entrega de webhook sigue un sobre consistente:

{
  "event": "check_in.completed",
  "version": "1",
  "timestamp": "2026-03-20T14:30:00Z",
  "delivery_id": "d_abc123",
  "data": {
    // Campos específicos del evento
  }
}

El campo version indica la versión del esquema del payload. Cuando se introducen cambios importantes, la versión se incrementa y puedes migrar a tu propio ritmo.

El delivery_id es único por intento de entrega, incluyendo reintentos. Úsalo para idempotencia — si tu endpoint recibe el mismo delivery_id dos veces, salta el duplicado.

Autenticación y verificación

Cada entrega incluye dos encabezados para verificación:

X-Dailybot-Signature — Digest hex HMAC-SHA256 del cuerpo crudo de la solicitud, calculado usando el secreto de firma de tu endpoint.
X-Dailybot-Timestamp — Timestamp Unix de cuándo se envió la entrega. Úsalo para rechazar entregas obsoletas (ej., más de 5 minutos) y prevenir ataques de replay.

Para verificar una entrega:

Lee el cuerpo crudo de la solicitud (no parses el JSON primero).
Calcula HMAC-SHA256 de {timestamp}.{body} usando tu secreto de firma.
Compara la firma calculada contra el encabezado X-Dailybot-Signature usando una comparación de tiempo constante.
Rechaza si el timestamp es más antiguo que tu ventana de tolerancia.

Política de reintentos

Si tu endpoint retorna un código de estado no-2xx o se agota el tiempo (límite de 30 segundos), Dailybot reintenta con backoff exponencial:

Intento	Espera
1er reintento	30 segundos
2do reintento	2 minutos
3er reintento	10 minutos
4to reintento	1 hora
5to reintento	6 horas

Después de 5 reintentos fallidos, la entrega se marca como fallida. Puedes ver el historial de entregas y reproducir entregas fallidas desde la página de configuración de webhooks.

Si un endpoint acumula demasiadas fallas consecutivas, Dailybot lo deshabilita automáticamente y envía una notificación al administrador del workspace. Reactívalo desde el dashboard después de corregir el problema.

Integraciones de ejemplo

Publicando alertas de bloqueantes en Slack

Suscríbete a eventos blocker.detected. Cuando el webhook se dispare, extrae user_name, original_response y matched_keywords del payload. Formatea un mensaje de Slack y envíalo con POST a tu canal #bloqueantes usando la API de Incoming Webhooks de Slack.

Disparando pipelines de CI/CD

Suscríbete a eventos agent_report.received. Cuando un agente reporta que una rama de feature está lista para revisión, parsea el campo metadata.branch y dispara tu pipeline de CI vía la API de GitHub Actions o GitLab.

Actualizando herramientas de gestión de proyectos

Suscríbete a eventos check_in.completed. Parsea las respuestas buscando menciones de tareas o palabras clave de estado, y actualiza las tarjetas correspondientes en Jira, Linear o Asana usando sus APIs. Esto mantiene los tableros de proyecto sincronizados con lo que la gente realmente reporta en sus standups.

Alertas al manager por ánimo

Suscríbete a eventos mood.threshold_crossed. Cuando el ánimo de un equipo cae por debajo de un puntaje configurado, envía un email o DM de Slack al manager del equipo con los datos de tendencia para que pueda hablar con el equipo proactivamente.

Buenas prácticas

Empieza con poco. Suscríbete a uno o dos tipos de eventos y construye desde ahí. Suscribirte a todo crea ruido antes de que tengas handlers para procesarlo.

Usa idempotencia. Tu endpoint puede recibir la misma entrega más de una vez debido a reintentos o problemas de red. Verifica el delivery_id antes de procesar.

Responde rápido. Retorna un código de estado 200 tan pronto recibas el payload. Haz el procesamiento pesado de forma asíncrona. Si tu endpoint toma demasiado tiempo, Dailybot reintentará y puedes procesar duplicados.

Monitorea la salud de las entregas. Revisa los logs de webhooks en Dailybot periódicamente. Un pico en fallas usualmente significa que tu endpoint está caído o retornando errores — captúralo antes de que el escalamiento deshabilite el endpoint.