Las automatizaciones se conectan con tus otros sistemas en los dos sentidos:

El paso Solicitud HTTP

Agrega un paso Solicitud HTTP desde la paleta (grupo Acciones) y completa:
Panel de Solicitud HTTP con método POST, URL, cuerpo con variables y Firmar la solicitud marcado
Por ejemplo, para mandar un lead a tu CRM:
Cuerpo

Salidas

Conecta siempre la salida Error. Por ejemplo, a un Pasar a una persona: si tu CRM está caído, el cliente igual recibe atención.

Usar la respuesta

Si en Guardar la respuesta en pones crm, después puedes usar:
  • {var.crm.status}: el código HTTP, por ejemplo 201.
  • {var.crm.body}: el cuerpo. Si es JSON, puedes entrar en él: {var.crm.body.id}, {var.crm.body.items[0].precio}.
Con Guardar partes de la respuesta le pones nombre propio a lo que te interesa. Por ejemplo, la ruta data.estado → variable estado te deja escribir “Tu pedido está {var.estado}” o usar una Condición sobre la Variable estado. Si la respuesta no es JSON, body queda como texto.

Probar la solicitud

En el panel del paso, Probar solicitud manda la solicitud tal cual (con las variables sin completar) y te muestra el código y el cuerpo de la respuesta. Sirve para revisar la URL y los encabezados antes de publicar. Puedes probar hasta 20 veces por minuto.

Qué no se puede

  • Llamar a direcciones internas (localhost, 192.168.…, 10.… y similares). La URL tiene que ser pública.
  • Esperar más de 10 segundos. Si tu sistema tiene que hacer algo largo, que responda enseguida con 202 y lo procese después.
  • Reintentos automáticos: si falla, sale por Error una sola vez.
Cada solicitud cuenta para el cupo de solicitudes HTTP por mes de tu plan (5.000 en Crecimiento, 50.000 en Escala). Las de Probar solicitud y las de pruebas con un contacto no cuentan.

Verificar la firma

Con Firmar la solicitud, cada pedido lleva el encabezado x-eltick-signature con el mismo formato que los webhooks de la API:
  • t: el momento de la firma, en segundos Unix.
  • v1: el HMAC-SHA256, en hexadecimal, de t, un punto y el cuerpo crudo del pedido (vacío en un GET).
La diferencia es la clave: en lugar del secreto whsec_… de un webhook, se firma con el token de la automatización (ats_…). Lo generas en el disparador Webhook entrante con Ver URL y token, y se muestra una sola vez. Si la automatización todavía no tiene token, la solicitud sale sin firma.
El token es uno por automatización y sirve para las dos cosas: firmar las solicitudes HTTP y autenticar el webhook entrante. Si generas uno nuevo, el anterior deja de valer para ambas.
Con esa respuesta, Guardar partes de la respuesta con la ruta id → variable id_lead te deja decirle al cliente “Tu número de consulta es {var.id_lead}”. Si la firma no coincide, revisa los mismos puntos que en los webhooks de la API: el cuerpo crudo, el token correcto y el reloj del servidor.

Webhook entrante

Con el disparador Webhook entrante, tu sistema arranca la automatización para un teléfono: eltick busca el contacto (o lo crea), abre su conversación de WhatsApp y recorre el flujo con los datos que mandaste.
Los webhooks entrantes están en los planes Escala y Enterprise, y solo funcionan con WhatsApp.

Configurarlo

1

Agrega el disparador

En el editor, elige Webhook entrante en Cuándo arranca.
2

Toca Ver URL y token

Copia la URL y genera el token. El token (ats_…) se muestra una sola vez: guárdalo en las variables de entorno de tu sistema.
Diálogo Webhook entrante con la URL, el token y un ejemplo con curl
3

Arma el flujo y publica

La automatización tiene que estar Activa para recibir llamadas.

La llamada

string
requerido
Teléfono del contacto, con código de país. Por ejemplo +5491123456789. Si no existe, se crea (y cuenta para el límite de contactos de tu plan).
string
Nombre del contacto, si lo sabes.
string
Desde cuál de tus números de WhatsApp escribir, si tienes varios. Si no lo mandas, se usa el primero que conectaste.
object
Lo que quieras usar en la automatización. Queda disponible como {var.webhook.…}: con {"pedido": "1042"} escribes {var.webhook.pedido}.
202
202 quiere decir que la ejecución arrancó. Lo que pase después (mensajes, respuestas, errores) lo ves en el historial de ejecuciones, o en tu sistema con los webhooks automation.completed y automation.failed.
Si la herramienta que usas no deja poner encabezados, puedes mandar el token en la URL: …/automations/{id}?token=ats_…. Evítalo si puedes, porque las URLs suelen quedar guardadas en registros.

Errores

Cada llamada cuenta como una llamada a la API y comparte sus topes (300 por minuto y 300.000 por mes en Escala). Mira Límites de la API.

Ten en cuenta la ventana de 24 horas

Una automatización que arranca desde tu sistema casi nunca tiene la ventana de 24 horas abierta: el cliente no te escribió hace poco. Por eso:
  • El primer mensaje tiene que ser una plantilla aprobada. Si usas un texto, conecta su salida Ventana cerrada a una plantilla.
  • No empieces con una Pregunta: fallaría con la ventana cerrada. Manda una plantilla con botones de respuesta rápida y arma otra automatización con un disparador de palabra clave con el texto del botón.
La receta Automatización desde tu sistema arma este caso completo.

Con la API

Si ya usas la API de eltick, puedes arrancar cualquier automatización activa con tu clave de API, sin token propio y sin necesidad de un disparador de webhook:
Usa el disparador Inicio manual de la automatización (o el primero, si no tiene). Mira la referencia de POST /automations/{id}/runs.