Deskhero
Español
Empieza gratis

← Back to articles

Qué hacen los webhooks de helpdesk y por qué son importantes

Qué hacen los webhooks de helpdesk y por qué son importantes

Un webhook de helpdesk es una solicitud HTTP saliente que envía eventos de tickets a otro sistema a medida que ocurren. Puede activar alertas, automatizaciones o sincronizaciones de datos sin realizar consultas frecuentes. Una integración fiable aún requiere una configuración cuidadosa: verifica cada solicitud, confirma las entregas rápidamente y prueba el endpoint antes de confiarle tráfico de producción.

En resumen:

  • Los webhooks pueden entregar actualizaciones de tickets con menos demora y menos llamadas a la API que las consultas frecuentes.
  • La configuración normalmente implica un endpoint HTTPS público, una suscripción a eventos, la verificación de solicitudes y pruebas con eventos representativos.
  • Los controles de seguridad dependen del proveedor, pero suelen incluir HTTPS, verificación mediante firma o token, rotación de secretos y procesamiento con los mínimos privilegios.
  • Los receptores deben tolerar eventos duplicados o fuera de orden mediante un procesamiento idempotente y la conciliación con el estado actual.
  • Deskhero actualmente no envía webhooks salientes. Su API REST puede consultarse cuando una integración personalizada necesita datos de tickets.

Tabla de contenidos

Cómo funcionan los webhooks de helpdesk: evento, POST y carga útil

Un webhook de helpdesk comienza con un evento. Alguien abre un ticket, un usuario cambia su estado, un cliente responde o cambia la prioridad. Si la plataforma ofrece un webhook para ese evento y te has suscrito a él, la plataforma envía una solicitud HTTP a la URL que registraste. A diferencia de las consultas realizadas según un horario fijo, el receptor no tiene que seguir preguntando si algo ha cambiado. Las cargas útiles de los webhooks suelen estar en formato JSON, aunque el formato y los campos exactos dependen del proveedor.

Diagrama de los campos de una carga útil JSON de webhook

Una carga útil de ticket creado podría incluir un ID de ticket, el estado, la prioridad, los datos del solicitante y la información sobre la causa del evento. No des por hecho que esos campos existen o que mantienen siempre la misma estructura. Trata el esquema de eventos actual del proveedor como la fuente de verdad y valida las cargas útiles antes de utilizarlas.

La diferencia práctica con las consultas está en el tiempo y el control. Un webhook puede notificar a tu receptor poco después de que ocurra un evento, mientras que un proceso de consultas detecta los cambios en su siguiente ejecución. Las consultas suelen ser más sencillas cuando las actualizaciones no son urgentes. Los webhooks son útiles cuando es importante reducir la demora y el proveedor admite los eventos y controles de seguridad que necesitas.

¿Cuáles son los mejores casos de uso de los webhooks de helpdesk?

Los webhooks son más valiosos cuando otro sistema necesita reaccionar rápidamente a un evento de ticket. Algunos ejemplos habituales son:

  • Alertas en canales. Un ticket nuevo o urgente puede activar una notificación en una herramienta de colaboración, si el helpdesk emite ese evento y la integración receptora lo admite.
  • Actualizaciones del CRM. La actividad seleccionada de un ticket puede copiarse en el registro de un cliente para que los equipos de soporte y ventas dispongan del contexto pertinente.
  • Activadores de escalamiento. Un evento urgente puede crear un incidente o una alerta en un sistema de guardias.
  • Ingesta de analíticas. Los eventos de tickets pueden alimentar una cola o una canalización de datos para generar informes posteriormente.
  • Coordinación entre sistemas. Un evento de ticket puede crear o actualizar un elemento de trabajo relacionado para otro equipo.

Estos flujos de trabajo aún necesitan un responsable claro y una gestión de errores. Un webhook es únicamente el mecanismo de entrega. El sistema receptor sigue siendo responsable de validar el evento, aplicar las reglas de negocio y recuperarse cuando los servicios posteriores no estén disponibles.

¿Cómo se configura un webhook de helpdesk?

El proceso exacto varía según la plataforma, pero una configuración típica sigue estos pasos:

  1. Lee la documentación del proveedor. Confirma los tipos de eventos disponibles, el esquema de la carga útil, el método de autenticación, el tiempo de espera, la política de reintentos y las funciones de registro de entregas.
  2. Expón un endpoint HTTPS público. Crea una ruta que acepte el formato de solicitud del proveedor. Muchos sistemas de webhooks utilizan solicitudes POST con JSON, pero tu implementación debe seguir el contrato documentado.
  3. Registra el endpoint y los eventos. Añade la URL mediante la interfaz de administración o la API de la plataforma y, después, suscríbete únicamente a los eventos que necesite tu integración.
  4. Configura la verificación de solicitudes. Si el proveedor emite un secreto de firma o un token de verificación, guárdalo en un gestor de secretos o en una variable de entorno protegida. Nunca lo incluyas directamente en el código fuente.
  5. Confirma rápidamente. Devuelve la respuesta correcta esperada antes de iniciar trabajos posteriores lentos. La documentación de webhooks de Stripe recomienda aplazar el procesamiento complejo hasta que el endpoint devuelva una respuesta correcta.
  6. Prueba antes de salir a producción. Utiliza los eventos de prueba del proveedor o un espacio de trabajo de desarrollo. Una herramienta segura de redireccionamiento puede ayudar durante el desarrollo local, pero no expongas un servicio de desarrollo sin protección al tráfico de producción.
  7. Comprueba los resultados de las entregas. Si el proveedor ofrece un registro de entregas, úsalo para comparar los eventos enviados con las respuestas de tu receptor y los registros de procesamiento.

Una confirmación rápida reduce la probabilidad de que el proveedor interprete un receptor lento como una entrega fallida. Poner en cola el evento verificado antes de continuar con el procesamiento también facilita reintentar tu propio trabajo sin pedir al remitente que lo reenvíe.

¿Cómo se protege un endpoint de webhook de helpdesk?

Una URL de webhook es accesible desde fuera de tu red, por lo que el receptor no debe confiar en una solicitud simplemente porque haya llegado a la ruta correcta.

Utiliza HTTPS con un certificado válido y una configuración TLS compatible actualmente. Después, implementa el mecanismo de verificación documentado por el proveedor. Puede tratarse de una firma HMAC, un token de verificación, firmas asimétricas u otro método. La verificación de firmas suele necesitar el cuerpo sin modificar de la solicitud, así que verifícalo antes de analizarlo o transformarlo.

Protégelo contra repeticiones cuando el mecanismo del proveedor admita marcas de tiempo o IDs de evento únicos. Compara las firmas en tiempo constante, rechaza las solicitudes no válidas y evita incluir secretos o datos personales en los registros de la aplicación. Rota los secretos cuando sea posible y documenta un procedimiento de solapamiento si los secretos antiguos y nuevos deben funcionar simultáneamente durante la rotación.

Concede al procesador del webhook únicamente los permisos que necesita. Si el proveedor publica rangos de direcciones IP de origen estables, una lista de permitidos puede ser un control adicional, pero no debe sustituir la verificación de solicitudes. Aplica límites de frecuencia con cuidado, supervisa los errores y conserva únicamente los datos del evento necesarios para el flujo de trabajo.

¿Cómo se protege un endpoint de webhook de helpdesk? Diagrama general

¿Cómo se prueban y depuran los webhooks de helpdesk?

Empieza por separar los problemas de entrega de los problemas de procesamiento. Confirma si el proveedor envió el evento, si la solicitud llegó a tu endpoint, qué respuesta devolvió el endpoint y si el evento aceptado completó su trabajo posterior.

  • Utiliza los eventos de prueba proporcionados por el proveedor cuando estén disponibles y, después, prueba eventos reales representativos en un espacio de trabajo que no sea de producción.
  • Registra un ID de evento, el tipo de evento, la hora de recepción, el resultado de la verificación, el estado de la respuesta y el resultado del procesamiento. Oculta los secretos y minimiza los datos personales almacenados.
  • Utiliza el registro de entregas de la plataforma para inspeccionar los códigos de respuesta y los reintentos. Zendesk documenta la actividad y los detalles de invocación de los webhooks para solucionar problemas de su servicio de webhooks.
  • Compara el registro de entregas del proveedor con los registros del proxy inverso y de la aplicación. La ausencia de encabezados o los cambios en el cuerpo pueden señalar una configuración incorrecta del middleware o del proxy.
  • Prueba los tiempos de espera, las firmas no válidas, los IDs de evento duplicados, los servicios posteriores no disponibles y los eventos entregados en un orden inesperado.

Consejo profesional: Conserva suficiente historial estructurado de entregas para rastrear los errores, pero establece un periodo de retención y evita registrar cargas útiles sin procesar a menos que sean realmente necesarias y estén protegidas adecuadamente.

¿Cómo deben gestionarse los eventos de webhook duplicados o fuera de orden?

No des por hecho que todos los eventos se entregarán exactamente una vez o que siempre llegarán en el orden de creación. El comportamiento de las entregas depende del proveedor y los reintentos pueden producir duplicados. La descripción general de Hookdeck compara los enfoques de entrega al menos una vez y exactamente una vez.

Haz que los controladores sean idempotentes. Cuando un proveedor proporcione un ID de evento estable, regístralo y evita aplicar dos veces la misma operación. Para los cambios de estado, utiliza marcas de tiempo o valores de secuencia si el proveedor los define y recupera el estado actual del recurso cuando la exactitud sea más importante que procesar cada transición intermedia. Pon en cola el trabajo fallido con reintentos limitados y retroceso progresivo, y envía los fallos persistentes a una cola de mensajes no entregables revisable o a un proceso equivalente.

La opción de API de Deskhero

Actualmente, Deskhero ofrece una API REST con tokens de portador personales, pero no envía webhooks salientes. Una integración que necesite datos de tickets de Deskhero debe consultar la API con un intervalo adecuado y respetar su límite de frecuencia. Este modelo es diferente de la entrega basada en eventos descrita anteriormente, así que planifica puntos de control, paginación, eliminación de duplicados y recuperación después de que falle un trabajo de consulta.

Elegir entre webhooks y consultas

Elige en función del sistema con el que te estás integrando, no suponiendo que todos los helpdesks admiten ambos modelos. Los webhooks pueden reducir la demora en la detección, pero requieren un receptor público y una gestión cuidadosa de las entregas. Las consultas necesitan programación y lógica de puntos de control, pero pueden ser más fáciles de operar y conciliar.

Deskhero

Deskhero convierte un buzón de Gmail o Microsoft 365 en un helpdesk compartido y conserva la dirección de correo electrónico existente de la empresa. Ofrece sincronización bidireccional de correo electrónico, automatizaciones de tickets integradas, borradores de respuestas generados por IA y basados en el conocimiento del espacio de trabajo, y una API REST para integraciones personalizadas. Las automatizaciones de Deskhero se ejecutan cuando se crean tickets nuevos; no sustituyen a los webhooks salientes. Los usuarios de Shopify también pueden conectar la integración de Shopify para consultar información relevante sobre pedidos y clientes en Deskhero. Hay una prueba gratuita de 30 días disponible sin tarjeta de crédito.

Dónde obtener más información sobre los estándares de webhooks

No existe un único estándar de webhooks que haga que todos los proveedores se comporten de la misma manera. Utiliza la documentación de tu proveedor como autoridad para los esquemas de eventos, la verificación, los reintentos y los tiempos de espera. La documentación de webhooks de Notion ofrece un ejemplo concreto de verificación de suscripciones y entrega de eventos.

Fuentes

Preguntas frecuentes

¿Qué son exactamente los webhooks?

Un webhook es una solicitud HTTP que un sistema envía a una URL registrada después de un evento definido. Contiene información que permite al sistema receptor decidir cómo reaccionar.

¿Cuáles son las desventajas de utilizar webhooks?

Los webhooks requieren un receptor seguro y accesible públicamente. La integración también debe tener en cuenta la verificación específica del proveedor, los reintentos, los eventos duplicados, el posible reordenamiento, las interrupciones, la supervisión y los cambios en los esquemas de eventos.

¿Qué es un webhook frente a una API?

Normalmente, una API permite que tu software solicite datos o active una acción. Un webhook permite que otro sistema envíe un evento a tu receptor. Muchas integraciones utilizan ambos: el webhook anuncia un cambio y la API proporciona los datos actuales del recurso.

¿Puedes darme un ejemplo de un webhook de helpdesk?

Un helpdesk compatible con webhooks salientes podría enviar un evento de ticket creado a tu receptor. Después de verificar la solicitud, tu integración podría añadir una notificación a un canal del equipo o actualizar un registro del CRM. Deskhero actualmente no envía webhooks salientes, por lo que las integraciones personalizadas de Deskhero deben consultar su API REST.