Webhooks salientes

El aviso que Dinaup envía por POST cuando se crea o modifica un registro: condiciones de disparo, cuerpo con previousData y newData, cabecera Bearer, cola de envío, reintentos y avisos por correo.

Un webhook saliente hace que Dinaup avise a tu servidor cuando cambia un registro de una sección. Configuras una URL y las condiciones, y el servidor de tu empresa envía un POST con el registro antes y después del cambio. El webhook se crea y se prueba en la pantalla Webhooks Salientes de Play.

Antes de empezar

La app Desarrollo en la licencia y el interruptor Desarrollador en tu usuario. Ver Desarrollo.
Una URL pública de tu servidor que acepte un POST con JSON y responda en menos de 30 segundos.

Cuándo se dispara

El servidor evalúa cada webhook activo después de guardar, en cada lote de cambios que reparte. Un webhook vigila una tabla: una sección de datos, una plantilla base o una tabla de líneas. Se dispara cuando se cumplen todas estas condiciones:

Condición	Qué comprueba
Evento	Disparar nuevos para las altas, Disparar modificaciones para las ediciones. Sin marcar ninguno, no sale nada.
Campos disparadores	Si eliges campos, una edición solo dispara cuando cambia alguno de ellos. En un alta todos los campos cuentan como cambiados. Sin campos, cualquier cambio dispara.
Campos obligatorios	Si eliges campos, tienen que estar rellenos en el registro tras el cambio. Un valor vacío o `0` cuenta como no relleno. 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; no hace falta reiniciar nada. Solo se evalúan los webhooks activos y no eliminados.

El aviso que recibe tu servidor

Un POST a la URL con Content-Type: application/json y, si rellenaste Bearer Token, la cabecera Authorization: Bearer <tu-token>. El cuerpo lleva dos objetos:

{
  "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"
  }
}

Objeto	Qué trae
`previousData`	El registro antes del cambio. En un alta puede llegar `null`: no hay estado anterior.
`newData`	El registro después del cambio.

Cada campo llega con su nombre de columna (pr_...) y su valor como texto, con los mismos formatos que la API: fechas yyyy-MM-dd HH:mm:ss en UTC, decimales con punto, booleanos 1 y 0, referencias como GUID. Los nombres de cada campo están en Desarrollo → Esquema de Play (Esquema).

Tu servidor confirma la entrega respondiendo con un código 2xx. Cualquier otro código, un error de conexión o pasar de 30 segundos cuentan como fallo.

Entrega y reintentos

Los avisos salen de una cola en el servidor de tu empresa:

Regla	Valor
Cadencia	Cada 3 segundos sale un lote de hasta 10 avisos en paralelo.
Tiempo de espera por aviso	30 segundos.
Intentos	3. Un aviso fallido vuelve al final de la cola y se reintenta en un lote posterior.
Tamaño de la cola	5.000 avisos. Con la cola llena, los avisos nuevos se descartan.
Orden	No garantizado: los reintentos salen después de los avisos nuevos.

Cuando un aviso agota los tres intentos se descarta y Dinaup envía un correo a tu empresa con el asunto Tu integración '<nombre>' ha dejado de responder. Al volver a entregar con éxito, envía Tu integración '<nombre>' vuelve a funcionar con el tiempo que estuvo caída. Mientras la avería sigue abierta no se repite el correo.

Un aviso descartado no se reenvía

Los webhooks avisan; no son una cola con reposición. Si tu servidor estuvo caído más de tres intentos, esos cambios no vuelven a salir. Para ponerte al día, consulta por la API los registros con fechaia posterior a la última entrega que procesaste.

Buenas prácticas

Práctica	Por qué
Responde `2xx` en cuanto guardes el aviso y procesa después	Tienes 30 segundos. Un procesamiento largo en línea acaba en reintento y en avisos duplicados.
Comprueba el Bearer Token	Descartas peticiones que no vienen de Dinaup.
Trata cada aviso como idempotente por `id`	Un reintento tras un tiempo de espera entrega el mismo cambio dos veces.
Acota con campos disparadores	Evitas avisos por campos que no te interesan, como los que actualiza el propio servidor.
Guarda lo que recibes	Con esa copia revisas un aviso cuando algo no coincide.

Probar antes de conectar

En Desarrollo → Conectar → Webhooks Salientes, el simulador envía un aviso real con los datos de un registro a la URL que le des. Lleva el mismo cuerpo y la misma cabecera. En la prueba previousData y newData son iguales. Ver Webhooks Salientes.

Relacionado

Eventos Redis: el mismo aviso por un canal de más caudal, en tu propio Redis.
Zapier, Make y n8n: un webhook saliente hacia un escenario sin programar.
Programar peticiones HTTP: cuando lo que necesitas es que Dinaup llame a una URL cada cierto tiempo.