🔂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:
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.
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.
Qué significan los estados
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.
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