Automatizaciones
Webhooks
La acción de webhook envía una llamada HTTP firmada a otro sistema en el momento en que algo ocurre en Gfacility, con tus propias cabeceras, tu propio payload y un ejemplo legible de lo que recibe el destinatario.
Actualizado el 25 jul 2026
Configuración · Automatización · 9.4
Un webhook es la mitad saliente de tu integración: en el momento en que un ticket, una reserva, un activo o un visitante cambia en Gfacility, sale una llamada HTTP hacia una URL que es tuya. Sin polling, sin exportación nocturna, sin middleware que vigilar. Es una de las siete acciones de 9.2 Automatizaciones, así que hereda los mismos disparadores, condiciones e historial de ejecución que cualquier otra acción.
Úsalo cuando el otro sistema tenga que reaccionar. Si lo que quieres es leer datos a tu propio ritmo, encajan mejor la API y el conector de Power BI.
Por qué esto importa al negocio
"Finanzas reescribe cada repercusión a mano"
Reserva cerrada, envía las líneas de repercusión directamente al sistema financiero.
"Nuestra página de estado va por detrás de la realidad"
Un incidente grave cambia de estado y la página pública se actualiza en segundos.
"Las tarjetas de acceso se piden demasiado tarde"
Visitante aprobado, avisa al sistema de control de accesos antes de que llegue.
"Los auditores quieren un rastro externo"
Los registros eliminados salen a tu propio almacén de registros, fuera de Gfacility.
Qué configuras
| Ajuste | Qué hace |
|---|---|
| URL del webhook | El endpoint HTTPS que recibe la llamada. |
| Aplicar a | De qué registro viajan los datos. Un ámbito hijo, como los visitantes de una reserva, envía una llamada por registro encontrado en lugar de una llamada con una lista. |
| Enviar los cambios de estos campos | El destinatario recibe el valor antiguo y el nuevo de cada campo que elijas. Déjalo vacío para enviar todos los campos que cambien. |
| Cabeceras propias | Para la autenticación del destinatario, por ejemplo Authorization o X-Api-Key. Se envían con cada llamada. |
| Payload adicional | JSON opcional que se incorpora a la llamada bajo "extra", para pasar un identificador de inquilino o una clave de enrutado que necesite el destinatario. |
| Cuerpo de la petición propio | Para un destinatario que exige su estructura exacta: tu JSON pasa a ser todo el cuerpo de la petición y el payload estándar del registro no se incluye. |
Tokens, para que el payload lleve valores reales
Los valores del payload adicional y de un cuerpo de petición propio admiten tokens, escritos con dobles llaves alrededor de una ruta de campo. El editor tiene un selector Insertar token con búsqueda, así no tienes que memorizar nombres de campo: eliges el campo y el token se escribe por ti. Al ejecutarse, cada token se sustituye por el valor de ese registro.
Es justo lo que convierte un cuerpo fijo en algo útil: el destinatario recibe el número de ticket, la ubicación y el correo del solicitante en lugar de un valor de ejemplo fijo.
Seguridad
Llamadas firmadas
Cada llamada lleva una cabecera de firma HMAC. Compruébala en tu lado antes de fiarte del cuerpo, para que un tercero no pueda falsificar una llamada a tu endpoint.
Cabeceras cifradas
Los valores de las cabeceras se guardan cifrados y se muestran enmascarados después de guardar. Deja la máscara tal cual para conservar el valor actual; nadie vuelve a leer tu clave de API desde el formulario.
Constrúyelo, míralo y solo entonces actívalo
El editor valida tu JSON mientras escribes, te dice cuándo no es válido y muestra un ejemplo de estructura válida. Al lado, Lo que recibe el destinatario muestra el payload real, así puedes compararlo con la documentación del otro sistema antes de que salga una sola llamada.
A partir de ahí se aplica el recorrido normal de automatización: ejecución de prueba de la regla sobre un registro real, revisar la entrada en el historial y activar.
¿Qué decisiones vas a tomar?
¿Payload estándar o cuerpo propio?
Estándar más payload adicional es más fácil de mantener. Pasa al cuerpo propio solo si el destinatario no se puede cambiar.
¿Qué campos necesita de verdad el destinatario?
Enviar todos los campos que cambian es cómodo pero ruidoso, y comparte más de lo que el destinatario necesita.
¿Quién es el dueño del endpoint?
Nombra un responsable en el lado receptor. Un webhook que nadie mantiene falla en silencio durante meses.
¿Qué pasa si falla?
Decide con "parar en la primera acción fallida" si el resto de la regla debe seguir ejecutándose.