Webhooks
La API BSP te permite configurar una URL de notificación por cliente. Cuando ocurren eventos sobre las plantillas, la plataforma hace un POST a esa URL con el payload del evento.
Consultar la configuración
Endpoint: GET /v1/webhook/config
Query params: client_id (opcional, requiere BSP_CN si difiere del token)
curl --request GET \
--url 'https://api.chattigo.com/v1/webhook/config?client_id=6' \
--header 'Authorization: Bearer <token>'Respuesta (200):
{
"id": 6,
"url": "https://mi-servidor.com/webhook/whatsapp",
"active": true
}Errores
| Código | Caso |
|---|---|
400 | client_id inválido |
403 | client_id distinto al del token sin BSP_CN |
404 | No existe configuración para ese cliente |
Crear o actualizar la configuración
Endpoint: PUT /v1/webhook/config
curl --request PUT \
--url 'https://api.chattigo.com/v1/webhook/config' \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '{
"client_id": 6,
"url": "https://mi-servidor.com/webhook/whatsapp"
}'| Código | Caso |
|---|---|
200 | Configuración guardada |
400 | url requerida, o client_id inválido |
403 | Cross-client sin BSP_CN |
Si no envías
client_id en el PUT, se usa el client_id del token.Notificación de eventos
Cuando la configuración está active, la API notifica a la URL con POST y Content-Type: application/json. El payload varía según el evento (saveCreatedEvent, saveUpdatedEvent, etc.).
Comportamiento del notificador
- Los eventos se envían de forma asíncrona — no bloquean la respuesta HTTP.
- Los errores de notificación se loguean sin fallar el request principal.
- El cliente HTTP usa timeouts y límites de conexión configurables.
Configuración del cliente HTTP
| Clave | Default | Descripción |
|---|---|---|
webhook.max_conns_per_host | 50 | Máximo de conexiones por host |
webhook.max_idle_conns_per_host | 50 | Máximo de conexiones idle por host |
webhook.idle_conn_timeout_secs | 10 | Timeout de conexiones idle |
webhook.max_idle_conns | 50 | Máximo de conexiones idle totales |
webhook.timeout_secs | 60 | Timeout de cada request |
Tu endpoint debe responder rápido y de forma idempotente: los eventos pueden repetirse y el notificador no reintenta en caso de error.