Registro de webhooks para entrega push

Los agentes de código ya envían avances a Dailybot a través de la superficie de reporting del agente. Los webhooks extienden ese modelo en la dirección opuesta: Dailybot notifica sus sistemas cuando ocurre algo relevante, para que las integraciones reaccionen casi en tiempo real sin polling.

Entrega push frente a polling

Polling significa que su servicio pregunta repetidamente «¿hay algo nuevo?» con un temporizador. Es fácil de entender, pero agrega latencia (solo se entera después del siguiente poll), consume cupo en respuestas vacías y aún arriesga perder secuencias rápidas si el intervalo es largo.

Entrega push invierte el flujo: Dailybot llama a una URL que ustedes controlan cuando se dispara un evento. Su código corre porque algo cambió, no porque sonó un cron. Para flujos de agentes—reportes recibidos, inbox actualizado, umbrales de salud cruzados—el push suele ser el mejor valor por defecto cuando operan un endpoint HTTPS alcanzable.

Registrar un endpoint de webhook

El registro suele hacerse en ajustes del workspace donde Dailybot expone integraciones salientes. Ustedes indican:

• Una URL HTTPS que el equipo controla (sin certificados autofirmados en producción).
• Metadatos opcionales como etiqueta, tag de entorno o a qué familias de eventos suscribirse, según lo que ofrezca la interfaz.

Después de guardar, Dailybot asocia esa URL con el workspace e intenta la entrega de los tipos de evento suscritos. Traten el registro como configuración documentada cuando sea posible: registren la URL, el servicio responsable y el procedimiento de rotación de secretos donde ya guardan API keys.

Forma del payload y lo que importa a los agentes

Los nombres de campo evolucionan con el producto, pero los cuerpos de webhook suelen ser JSON e incluyen:

• Un tipo de evento o categoría para ramificar lógica sin inferir desde payloads parciales.
• Un timestamp o identificador de evento para orden y deduplicación.
• Contexto que enlaza el evento con workspace, proyecto o identidad del agente—alineado con lo que ya envían en reportes y metadata.

Piensen el webhook como un espejo estructurado de la actividad que sus agentes ya generaron: un reporte enviado, un digest listo o un gancho de automatización downstream. El parseo debe ser defensivo: pueden aparecer campos desconocidos cuando Dailybot agrega capacidades; ignoren lo que no necesiten.

Autenticación y verificación de las llamadas

Como la URL está en internet público, cualquier cliente HTTP podría hacer POST. La verificación cierra esa brecha.

Las integraciones estilo Dailybot suelen incluir un secreto compartido o firma HMAC sobre el cuerpo en bruto de la solicitud. Su handler debería:

1. Leer el cuerpo en bruto antes del parseo JSON para verificar la firma.
2. Calcular la firma esperada con el algoritmo y secreto documentados.
3. Comparar con comparación en tiempo constante para resistir ataques de timing.
4. Opcionalmente aplicar una ventana de desfase de timestamp si las firmas incluyen claims temporales.

Nunca registren secretos completos ni material de firma sin redactar. Roten secretos cuando alguien salga del equipo o si sospechan exposición.

Reintentos, errores y diseño del handler

Los emisores de webhook casi siempre reintentan ante fallo: cortes de red, despliegues y sobrecarga son normales. Esperen entrega al menos una vez: el mismo evento lógico puede llegar más de una vez.

Respondan 2xx en cuanto hayan validado y persistido lo suficiente para terminar el procesamiento después. Transacciones largas en base de datos o llamadas a terceros deberían correr de forma asíncrona después de acusar recibo del HTTP—si no, Dailybot puede agotar tiempo de espera y reintentar mientras el trabajo sigue corriendo.

Si devuelven 4xx por payloads mal formados, el emisor puede no reintentar (bug suyo). Si devuelven 5xx o tiempo de espera, esperen reintentos con backoff. Implementen claves de idempotencia desde IDs de evento para que entregas duplicadas no creen tickets, cargos o despliegues duplicados.

Buenas prácticas de seguridad y operación

• Usen solo HTTPS y mantengan TLS al día en su ingress.
• Autentiquen cada solicitud de forma criptográfica; no confíen solo en que la URL sea oscura.
• Delimiten el secreto del webhook por entorno (staging frente a producción).
• Apliquen rate limiting y monitoreen su endpoint ante abuso ajeno a Dailybot.
• Alerten ante tasas de error altas para que un desvío silencioso no rompa la automatización impulsada por agentes.

Cómo encaja en el sistema amplio de reporting de agentes

El reporting del agente es la fuente de verdad de lo que hicieron los agentes de código: mensajes estilo standup, JSON estructurado para milestones, señales de salud y pulls del inbox. Los webhooks son la capa de fan-out: permiten que CI, tableros internos u orquestadores reaccionen en el momento en que existe información nueva—sin reemplazar llamadas API autenticadas para acciones que deben originarse en su agente o servicio.

En conjunto, el modelo es: los agentes envían a Dailybot; Dailybot almacena y muestra visibilidad a humanos; los webhooks opcionalmente notifican otros sistemas en cuanto hay nueva información—sin sustituir el API autenticado.

---

Para esquemas a nivel de campo y la lista de eventos más reciente, consulten la documentación oficial para desarrolladores de Dailybot junto con los ajustes del workspace.