Skip to main content
Un webhook conecta un evento de ContactShip con una URL de tu sistema. No hay un único webhook para toda la plataforma: elegí el que corresponda al momento y a los datos que necesitás.

​
Elegí el evento

​
Qué envía cada uno

Llamada analizada

ContactShip envía: { "data": { "agent": {}, "organization": {}, "call": {}, "campaign": {}, "contact": {} } }, con bloques condicionales.Llega después del análisis; puede esperar evaluaciones. Tu receptor acepta el evento con HTTP 2xx. La configuración y los intentos se revisan en Webhooks de llamadas. Consultá los campos y ejemplos exactos.
ContactShip envía: call con dirección y teléfonos, agent_id, organization_id y contact cuando está disponible.Tu sistema responde: un objeto JSON con los datos que el agente necesita, por ejemplo saldo o estado de un pedido. La respuesta se usa durante la conversación; no es el resultado final. Ver contrato de contexto de entrada.
Seleccionás INSERT, UPDATE o DELETE: describen conversaciones, no cada mensaje individual. Configurá URL e interruptor en Canal → Avanzado.Capturá un evento controlado en tu receptor para mapear los campos de ese canal. No apliques el esquema data.call a estos eventos. Para controlar explícitamente el cuerpo enviado, usá una automatización con Body template.
Elegís el disparador y las condiciones de la regla. La acción permite URL, método POST, PUT o PATCH, headers y Body template. Con cuerpo vacío, envía el contexto completo del evento.Definí un cuerpo propio con las variables que necesitás. En Run History, abrí Trigger Payload y el Output de la acción para comprobar los valores disponibles y el resultado. Ver automatizaciones del inbox.
Envía event: "follow_up_closed", threadId, agentId, motivo de cierre, etapas, fecha, contacto y resumen. Es un cuerpo distinto al webhook de voz, sin envoltorio data.No representa todos los cierres manuales del inbox. Ver campos y ejemplo de cierre y configuración de seguimientos.
El webhook fuera de horario notifica al receptor con un POST cuando se aplica esa regla del canal. Configuralo en Respuestas y verificá un mensaje controlado en tu receptor.Los avisos de enrutamiento describen asignación y plazos; la pantalla actual no expone un editor público de su webhook. Coordiná el contrato con soporte según Condiciones, avisos y webhooks. No reutilices una firma ni un parser de otro tipo de webhook.

​
Cómo probar una integración

1

Separá los receptores

Usá rutas o workflows distintos para voz, contexto de entrada y mensajes. Cada uno puede esperar otro cuerpo o respuesta.
2

Provocá un evento controlado

Hacé una prueba del caso real: llamada, mensaje, cierre o cambio de conversación. No uses un JSON de ejemplo como prueba de entrega.
3

Conservá el cuerpo y la respuesta

Revisá los datos en tu receptor. Para voz, compará con Llamadas → Webhooks; para reglas del inbox, con Run History.
4

Verificá la acción final

Comprobá el ticket, tarea o actualización en tu sistema. Una respuesta HTTP exitosa no demuestra por sí sola que esa acción terminó.
Los reintentos, los headers y las firmas dependen del tipo de webhook. El webhook de llamadas no agrega la firma del enrutamiento, y el cierre de seguimiento no comparte su mecanismo de reintentos.

​
Preguntas frecuentes

Solo si tu receptor distingue los contratos. Separar rutas simplifica el mapeo y evita responder al webhook de contexto como si fuera una notificación.
En los logs o historial de tu receptor. Para llamadas, también en Llamadas → Webhooks. En automatizaciones, revisá Trigger Payload y los pasos de Run History.
No. Sus eventos son de conversación. Para mensajes nuevos, elegí ese disparador en una automatización.

​
Seguí con

Webhook de llamadas

Campos y ejemplos completos.

Integrar tu sistema

Recorrido desde la API hasta el resultado.