Nodo: Webhook de Salida

El nodo Webhook de Salida realiza una llamada HTTP a una URL externa durante la ejecución del workflow. Con él, puedes integrar Hashdata con cualquier sistema que tenga una API REST — sin necesitar un conector nativo dedicado. Cada vez que una instancia pasa por este nodo, Hashdata envía una solicitud a la dirección configurada y espera la respuesta antes de continuar al siguiente paso.

Este nodo es el puente universal entre tus procesos en Hashdata y el mundo exterior: CRMs, ERPs, sistemas de soporte, plataformas de e-commerce, automatizaciones internas y cualquier otro servicio que acepte solicitudes HTTP.

Cuándo Usar

El nodo de Webhook de Salida es indicado en las siguientes situaciones:

• Integrar con sistemas sin conector nativo: cuando el servicio que necesitas activar no tiene una integración lista en Hashdata (como Slack, Google Sheets o Teams), el webhook permite comunicación directa vía API.
• Activar automatizaciones en CRM o ERP: al recibir una respuesta de formulario, puedes crear automáticamente un contacto en tu CRM, abrir un ticket en el ERP o actualizar un registro en cualquier sistema con API REST.
• Enviar datos en tiempo real: en lugar de exportaciones periódicas, el webhook garantiza que los datos lleguen al sistema de destino en el momento exacto en que la instancia pasa por este nodo.
• Sincronizar sistemas: mantén dos sistemas sincronizados disparando llamadas a APIs de terceros conforme avanza el flujo.
• Notificar plataformas externas: informa a sistemas de monitoreo, plataformas de BI o herramientas de comunicación sobre eventos ocurridos dentro del workflow.

Configuración

Para configurar el nodo, haz clic sobre él en el canvas del editor de workflow. El panel lateral mostrará las opciones a continuación.

Campo	Obligatorio	Descripción
URL	Sí	Dirección completa de la API que recibirá la solicitud. Debe comenzar con https://. Las URLs con HTTP simple no son aceptadas por razones de seguridad.
Método HTTP	Sí	Verbo HTTP de la solicitud: GET, POST, PUT, PATCH o DELETE. Elige según la documentación de la API de destino.
Tipo de contenido	Solo para POST y PATCH	Define el formato del cuerpo de la solicitud. Opciones: JSON (application/json) o Formulario URL-encoded (application/x-www-form-urlencoded). Consulta la documentación de la API de destino para saber qué formato espera.
Headers	No	Pares de clave y valor enviados en el encabezado de la solicitud. Úsalos para autenticación (ej.: Authorization: Bearer TU_TOKEN) o para instrucciones específicas de la API (ej.: Content-Type, Accept, x-api-key).
Parámetros de URL	No	Parámetros de query string agregados automáticamente al final de la URL. Por ejemplo, agregar la clave estado con valor activo resultará en ?estado=activo en la URL final.
Estructura del cuerpo (body)	Sí	Simple (campos personalizables): en esta opción el usuario podrá elegir qué información desea enviar al sistema externo. Respuesta Completa: en esta opción el sistema enviará toda la información disponible de un formulario, es decir, el usuario no necesita elegir una por una.

Solo HTTPS es aceptado

Hashdata rechaza URLs que utilicen HTTP simple. Asegúrate de que la API de destino tenga un certificado SSL válido y que la URL comience con https://. Esta restricción existe para proteger los datos sensibles que viajan entre Hashdata y los sistemas externos.

Salidas del Nodo

El nodo de Webhook de Salida tiene dos salidas en el canvas, y debes conectar cada una al tratamiento adecuado:

• Éxito: se activa cuando la API responde con un código HTTP en el rango 2xx (200, 201, 204, etc.). Indica que la llamada fue realizada y aceptada por el sistema de destino. El flujo continúa normalmente por esta salida.
• Error: se activa cuando la API responde con un código HTTP fuera del rango 2xx (ej.: 400, 401, 403, 404, 500) o cuando ocurre un fallo de red (timeout, host inalcanzable, error de DNS). Usa esta salida para tratar fallos — por ejemplo, enviando una notificación por correo o activando un flujo alternativo.

Conectar ambas salidas es considerado una buena práctica. Si la salida de Error queda desconectada, las instancias que fallen en este nodo pueden quedar atascadas o finalizar sin tratamiento adecuado.

Autenticación

La mayoría de las APIs requieren alguna forma de autenticación para aceptar solicitudes externas. El nodo de Webhook de Salida soporta los mecanismos más comunes a través de los Headers:

Token Bearer (OAuth 2.0 / JWT)

Agrega un header con la clave Authorization y el valor Bearer TU_TOKEN_AQUÍ. Reemplaza TU_TOKEN_AQUÍ con el token de acceso proporcionado por la API de destino.

API Key en el Header

Muchas APIs usan una clave de API transmitida en un header específico. Consulta la documentación de la API para saber el nombre correcto del header — ejemplos comunes son x-api-key, api-key o X-Auth-Token. Agrega el par clave-valor correspondiente en la sección de headers del nodo.

API Key en la URL

Algunas APIs aceptan la clave de API como parámetro de URL. En ese caso, usa la sección Parámetros de URL para agregar el par clave-valor, manteniendo la clave fuera del campo de URL principal para facilitar el mantenimiento.

Nunca incluyas tokens directamente en la URL

Evita incrustar credenciales, tokens o claves de API directamente en el campo de URL (como https://api.ejemplo.com?token=MI_CLAVE). Las URLs pueden registrarse en logs de acceso y quedar expuestas inadvertidamente. Usa siempre el campo de Headers o Body con POST para información sensible, y prefiere los headers para autenticación.

Seguridad

Al configurar el nodo de Webhook de Salida, sigue estas buenas prácticas para garantizar la seguridad de tus integraciones:

1. Usa solo HTTPS: garantiza que la API de destino soporte conexiones seguras. Hashdata bloquea llamadas a URLs HTTP.
2. Mantén los tokens en los headers: las credenciales y claves de API siempre deben estar en el campo de Headers, nunca en la URL ni en el cuerpo de la solicitud en texto plano.
3. Revoca tokens no utilizados: si un workflow se desactiva o la integración ya no es necesaria, revoca el token de acceso en el sistema de destino.
4. Prefiere tokens de alcance limitado: al generar credenciales para el webhook, otorga solo los permisos estrictamente necesarios para la operación que realiza el nodo.
5. Monitorea la salida de Error: supervisa las instancias que pasan por la salida de Error para detectar intentos de llamada con credenciales expiradas o APIs no disponibles.

Timeout y Tratamiento de Fallos

Timeout de 10 segundos

Hashdata espera como máximo 10 segundos por la respuesta de la API de destino. Si la API tarda más de eso en responder, la llamada se termina y la instancia sigue por la salida de Error. Las APIs lentas, sobrecargadas o geográficamente distantes pueden causar timeouts frecuentes. En ese caso, verifica el rendimiento de la API de destino o considera usar una cola asíncrona en el sistema receptor.

Para manejar fallos de forma robusta en tu workflow:

1. Conecta la salida de Error a un nodo de Enviar Correo para notificar a los responsables sobre el fallo.
2. Usa un nodo de Definir Estado para registrar que la instancia está esperando intervención manual.
3. Considera agregar un nodo de Aprobación en la salida de error, permitiendo que un administrador decida cómo proceder.

Ejemplos de Uso

• Crear lead en CRM: al recibir una respuesta de formulario de interés, disparar un POST a la API del CRM con los datos del respondente y registrar el ID del lead creado vía modo full-response.
• Abrir ticket en el sistema de soporte: cuando una aprobación se completa con resultado negativo, enviar los detalles a la API del sistema de soporte para la apertura automática de un ticket.
• Notificar sistema de logística: al recibir un pedido vía formulario, activar la API del sistema de logística para iniciar la separación del producto.
• Sincronizar con ERP: tras una aprobación de presupuesto, enviar los datos aprobados a la API del ERP y usar el número de documento generado en los siguientes nodos del workflow.