Dinaup DocsWebhooks salientes
El aviso que Dinaup envía por POST cuando se crea o modifica un registro: condiciones de disparo, cuerpo con previousData y newData, cola de envío, reintentos y avisos por correo.
Un webhook saliente hace que Dinaup envíe un POST a tu servidor cuando cambia un registro de una sección, con el registro antes y después del cambio. Se crea y se prueba en Desarrollo → Conectar → Webhooks Salientes (Webhooks Salientes).
Antes de empezar
- La app Desarrollo en la licencia y el interruptor Desarrollador en tu usuario. Ver Desarrollo.
- Una URL pública que acepte un
POSTcon JSON y responda en menos de 30 segundos.
Cuándo se dispara
Un webhook vigila una tabla: una sección de datos, una plantilla base o una tabla de líneas. Dispara cuando se cumplen las tres condiciones:
| Condición | Qué comprueba |
|---|---|
| Evento | Disparar nuevos para las altas, Disparar modificaciones para las ediciones. Sin ninguno marcado, no sale nada. |
| Campos disparadores | Si eliges campos, una edición solo dispara cuando cambia alguno. En un alta todos cuentan como cambiados. Sin campos, cualquier cambio dispara. |
| Campos obligatorios | Si eliges campos, tienen que estar rellenos tras el cambio (vacío o 0 no cuenta). Con Todos los campos seleccionados hacen falta todos; con Al menos un campo, basta uno. |
Un webhook nuevo o editado entra en vigor en el siguiente lote de cambios. Solo cuentan los activos y no eliminados.
El aviso que recibe tu servidor
Un POST con Content-Type: application/json y, si rellenaste Bearer Token, la cabecera Authorization: Bearer <tu-token>:
{
"previousData": {
"id": "123e4567-e89b-12d3-a456-426614174000",
"pr_cliente": "0f5d1c2a-...",
"pr_importe": "100.00"
},
"newData": {
"id": "123e4567-e89b-12d3-a456-426614174000",
"pr_cliente": "0f5d1c2a-...",
"pr_importe": "150.00"
}
}previousData es el registro antes del cambio (en un alta puede llegar null) y newData, después. Cada campo llega con su nombre de columna (pr_...) y su valor como texto, con los formatos de la API: fechas yyyy-MM-dd HH:mm:ss en UTC, decimales con punto, booleanos 1 y 0, referencias como GUID. Los nombres están en Desarrollo → Esquema (Esquema).
Tu servidor confirma con un 2xx. Otro código, un error de conexión o pasar de 30 segundos cuentan como fallo.
Entrega y reintentos
| Regla | Valor |
|---|---|
| Cadencia | Cada 3 segundos sale un lote de hasta 10 avisos en paralelo. |
| Tiempo de espera | 30 segundos por aviso. |
| Intentos | 3. Un aviso fallido vuelve al final de la cola. |
| Tamaño de la cola | 5.000 avisos. Con la cola llena, los nuevos se descartan. |
| Orden | No garantizado: los reintentos salen después de los avisos nuevos. |
Un reintento tras pasar los 30 segundos entrega el mismo cambio dos veces. Acota con campos disparadores para no recibir avisos por campos que no te interesan, como los que actualiza el propio servidor.
Cuando un aviso agota los tres intentos se descarta y Dinaup envía a tu empresa un correo con el asunto Tu integración '<nombre>' ha dejado de responder. Al volver a entregar, envía Tu integración '<nombre>' vuelve a funcionar con el tiempo caído.
Un aviso descartado no se reenvía
Para ponerte al día tras una caída, consulta por la API los registros con fechaia posterior a la última entrega que procesaste.
Probar antes de conectar
En Desarrollo → Conectar → Webhooks Salientes, el simulador envía un aviso real con un registro a la URL que le des, con el mismo cuerpo y la misma cabecera. En la prueba previousData y newData son iguales.
Para el mismo aviso con más caudal y en tu propio Redis: Eventos Redis.