Cómo configurar webhooks salientes en Xcellerate OPS

Xcellerate OPS genera un evento cada vez que ocurre algo: se crea un ticket, se acepta un presupuesto, se crea una factura, se pierde una llamada. Con los webhooks salientes envías esos eventos en JSON a tu propia URL, para que Zapier, Make, n8n, Power Automate o tu propio sistema actúen de inmediato. Esta guía es para administradores de MSP y empresas de servicios que quieren que OPS impulse el resto de sus herramientas.

TL;DR

• Ve a Settings → Data and security (Datos y seguridad) → Notifications and webhooks (Notificaciones y webhooks) y añade una URL por evento.
• OPS envía al momento un POST JSON por evento, firmado con HMAC-SHA256 si lo deseas.
• Cada entrega se envía una sola vez, sin reintentos: elige un receptor siempre disponible que responda rápido.

Antes de empezar

• Tienes el rol admin en tu espacio de trabajo de OPS.
• Tienes un endpoint que acepta solicitudes POST con Content-Type: application/json y responde en menos de 8 segundos.
• La URL apunta a una dirección pública. Las direcciones privadas o internas se rechazan. Usa HTTPS siempre que puedas.
• Opcional: un secreto compartido para que tu receptor verifique la firma.

Configurar un webhook saliente

Paso 1: Abre la página de eventos

Ve a Settings → Data and security (Datos y seguridad) → Notifications and webhooks (Notificaciones y webhooks). Los eventos están agrupados por área. Sus nombres aparecen en inglés con su clave técnica, por ejemplo «Ticket created» (ticket.created).

La página Notifications and webhooks, con opciones por evento para avisar al asignado, correo al cliente, plantilla de correo y un botón para añadir un webhook.

Paso 2: Añade un webhook a un evento

Busca el evento que quieres reenviar y haz clic en Add webhook (Añadir webhook). Introduce la URL de tu receptor.

Paso 3: Define un secreto de firma (opcional)

Rellena Signing secret (optional) (Secreto de firma, opcional). Cada solicitud llevará entonces la cabecera X-Signature: sha256=<hex>: un HMAC-SHA256 del cuerpo JSON sin procesar, calculado con tu secreto. Tu receptor calcula el mismo valor y lo compara. Después de guardar, el secreto no se vuelve a mostrar. Si dejas el campo vacío al guardar, se conserva el secreto guardado.

Paso 4: Envía una prueba

Haz clic en Test (Probar) para enviar un payload de ejemplo de ese evento. La prueba solo confirma que OPS pudo enviar la solicitud. No indica qué hizo tu endpoint con ella. Por eso, comprueba siempre en el lado del receptor, en el historial o los registros de tu herramienta, que el ejemplo llegó y se procesó correctamente.

Paso 5: Guarda y repite

Haz clic en Save (Guardar) en la parte superior de la página. Repite con cada evento que quieras reenviar: defines una URL por tipo de evento.

Qué ocurre después de conectar

• Dirección: de OPS a tu URL. Un POST por evento, enviado en el momento en que ocurre.
• Contenido: todos los mensajes tienen la misma estructura. El campo data cambia según el evento.

{
  "event": "ticket.created",
  "label": "Ticket created",
  "occurredAt": "<ISO-8601>",
  "title": "…",
  "link": "/tickets/…",
  "data": { … }
}

• Cobertura: más de 160 tipos de eventos, entre ellos tickets, clientes y contactos, tareas de CRM, proyectos, presupuestos de proyecto, partes de horas, facturas, contratos, presupuestos, activos, llamadas, oportunidades, tiempo de trabajo, cambios, problemas e incidentes ITIL y compañeros de IA.
• Notificaciones: en la misma página controlas por evento las notificaciones dentro de la aplicación, Notify assignee (Avisar al asignado) y las plantillas de correo a clientes para eventos de tickets.

Descubre más sobre la automatización en OPS y las integraciones europeas y la seguridad.

Conviene saber

• Se envía una vez, sin reintentos. No hay reintentos ni registro de entregas. Si tu receptor está caído o es demasiado lento, ese evento no llega. Usa un receptor fiable: una plataforma de automatización o un endpoint propio que guarde el mensaje, responda al instante y lo procese después.
• Tiempo de espera de 8 segundos, y las redirecciones no se siguen. Usa la URL final.
• Una URL por tipo de evento. Si varios sistemas necesitan el mismo evento, deja que tu receptor lo reparta.
• Las importaciones masivas y las fusiones nunca disparan webhooks.
• En el momento del envío se vuelve a comprobar que la URL apunta a una dirección pública.

Solución de problemas

• «Sample payload sent.» La solicitud de prueba salió. Comprueba en tu receptor que también se procesó.
• «Webhook test failed: » Un fallo a nivel de conexión, como DNS, tiempo de espera o TLS.
• Error de validación al guardar. La URL no es válida o apunta a una dirección privada o interna.
• Los eventos reales no llegan, aunque la prueba funcionó. Comprueba que tu endpoint responde rápido, sin redirecciones, y sigue accesible en una dirección pública.

Empieza

¿Quieres que OPS pase tus tickets, presupuestos y facturas al resto de tus herramientas? Empieza gratis y configura tu primer webhook desde los ajustes.