For the complete documentation index, see llms.txt. This page is also available as Markdown.

🔂Entrega, reintentos e historial

Cómo entrega Dapta Forms las respuestas a webhooks, HubSpot y correo sin bloquear nunca a quien responde: la cola, el calendario de reintentos con backoff, qué significan Entregado, En curso, Fallido

Cada integración de Dapta Forms sigue la misma regla: guardar la respuesta primero, entregar después, reintentar si falla, y dejar registro. Esta página explica ese proceso para que sepas qué esperar cuando un endpoint va lento, un CRM está caído, o alguien envía dos veces.


Nada bloquea una respuesta

Cuando alguien pasa el punto de envío parcial o termina el formulario, sus respuestas se guardan de inmediato y ve el siguiente paso o la pantalla final. Solo entonces Dapta Forms encola una entrega por cada integración activada:

Integración
Qué se encola
En qué fase

Webhook

Un POST por webhook

Parcial o completa, según las casillas de Disparar en

HubSpot

Alta o actualización del contacto y propiedades mapeadas

Parcial y completa (puntaje, resultado, propiedades estáticas, nota y actividad de envío de formulario solo en la completa)

Correos

Aviso de nueva respuesta y Confirmación al encuestado

Solo completa

Sincronización de reservas

Propiedades de reserva de HubSpot

Después de una reserva en el agendador

Un destino lento o roto, por tanto, nunca ralentiza a quien responde, y nunca pierde las respuestas: el envío ya está en Respuestas y en el CSV antes de que se intente ninguna entrega.


Calendario de reintentos

Una entrega se recoge en unos segundos. Si falla (estado distinto de 2xx, redirección, tiempo agotado a los 10 segundos, error de red, error del proveedor) se reintenta con backoff exponencial: unos 1 s, 2 s, 4 s, 8 s… entre intentos, con tope de 5 minutos, hasta un máximo de 5 intentos. Mientras hay reintentos pendientes la fila dice En curso y el conteo de intentos sube.

El diálogo Historial de webhook con dos filas marcadas En curso, HTTP 500, 2 intentos
Entre reintentos, una entrega se muestra como En curso con su conteo de intentos.

Tras el quinto fallo la entrega se marca como Fallida y se conserva como registro, con el último error y la última respuesta del endpoint.

Una fila Fallida desplegada en el diálogo Historial de webhook mostrando 5 intentos, el cuerpo en Qué enviamos y la respuesta en Qué volvió HTTP 500
Una entrega que se rindió tras 5 intentos. La transcripción sigue disponible.

Qué significan los estados

El diálogo Historial de webhook listando filas Entregado, algunas con una insignia Prueba
Píldoras de estado y la insignia Prueba en un diálogo de historial.
Estado
Qué significa
¿Se reintenta?

Entregado

El destino la aceptó (2xx en un webhook, una llamada de API correcta en HubSpot, el correo entregado al proveedor).

No hace falta.

En curso

Encolada, enviándose, o esperando su siguiente intento.

Sí, automáticamente.

Fallido

Reintentos agotados. La fila conserva el último mensaje de error y, en los webhooks, Qué volvió.

No. Arregla el destino; la siguiente respuesta o Enviar prueba pasará.

Omitido

No se hizo a propósito porque ya no podía aplicar (por ejemplo una sincronización de reserva en un formulario cuyo destino de HubSpot se apagó entretanto). Se registra una vez con un motivo, nunca se reintenta.

No.

⚠️ Nota: No hay botón de reenvío manual. Las entregas fallidas son un registro, no una cola que puedas reproducir. Si se perdió un lead porque tu endpoint estaba caído, exporta la respuesta desde Respuestas o pídele a la persona que vuelva a enviar.


Historial por integración

Cada tarjeta de la pestaña Conectar tiene su propio registro: Historial de webhook, Historial de HubSpot e Historial de correos, cada uno se abre con Ver historial y muestra las últimas 25 filas, de la más reciente a la más antigua. Las filas de webhook incluyen la petición y la respuesta completas; las de HubSpot incluyen la acción y cualquier error que devolviera el CRM; las de correo muestran qué aviso se envió.

A nivel de cuenta, el inventario de Webhooks de la página de Conexiones muestra una columna de Entrega por formulario: vacía cuando está sano, o un {n} fallidas rojo con Último fallo {fecha}. Los fallos se cuentan por formulario, así que un formulario con dos webhooks muestra el mismo conteo en las dos filas.

La tabla de Webhooks de la página de Conexiones con una insignia roja de 4 fallidas en la columna Entrega
El inventario marca los formularios cuyo webhook tiene entregas fallidas.

Sin duplicados al reenviar

Cada entrega lleva una clave de idempotencia (submission:{submissionId}:{phase}:webhook:{index}, enviada como x-forms-delivery y como id en el cuerpo). Si la misma sesión envía otra vez la misma fase, por ejemplo porque la persona volvió atrás y pulsó Enviar dos veces, las entregas pendientes de esa fase se reemplazan en lugar de duplicarse, y una fase que ya llegó no se vuelve a encolar. HubSpot se indexa por el correo de quien responde, así que una repetición actualiza el mismo contacto en lugar de crear uno nuevo. En tu propio endpoint, guarda la clave e ignora una petición cuya clave ya procesaste.

Qué sigue

Última actualización