> For the complete documentation index, see [llms.txt](https://docs.dapta.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dapta.ai/dapta-docs-es/dforms/connect/delivery-and-retries.md).

# Entrega, reintentos e historial

Cómo entrega dForms las respuestas a webhooks, HubSpot y correo sin bloquear nunca a quien responde: la cola, el calendario de reintentos con backoff, qué significan Entregada, En curso, Falló y Omiti

Cada integración de dForms 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 dForms encola las entregas de 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 form submission solo en la completa) |
| **Correos**                    | Un **Aviso de nueva respuesta** por cada dirección de **Enviar a**, y la **Confirmación al encuestado** | Solo completa                                                                                                           |
| **Sincronización de reservas** | Propiedades de reserva de HubSpot                                                                       | Después de una reserva en el agendador, unos 15 segundos más tarde                                                      |

En una pantalla de Diapositivas que muestra varias preguntas, la parcial se envía cuando la persona envía la pantalla que contiene el punto de envío parcial. Con la [protección contra spam](/dapta-docs-es/dforms/connect/spam-protection.md) activa, una parcial se guarda pero no se encola nada para los webhooks ni para HubSpot: solo se entrega la respuesta completa y verificada.

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.

<figure><img src="https://365551146-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMUYDYzjmxpzlYaw0gcaZ%2Fuploads%2Fgit-blob-3d8c936536e7236c37a256b1ee2c62ca61b1c1a8%2Fforms-delivery-and-retries-02-in-progress.png?alt=media" alt="El diálogo Historial del webhook con dos filas marcadas En curso, HTTP 500, 2 intentos"><figcaption><p>Entre reintentos, una entrega se muestra como <strong>En curso</strong> con su conteo de intentos.</p></figcaption></figure>

Tras el quinto fallo la entrega queda marcada con **Falló** y se conserva como registro, con el último error y la última respuesta del endpoint.

<figure><img src="https://365551146-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMUYDYzjmxpzlYaw0gcaZ%2Fuploads%2Fgit-blob-ee911d78e8cb9ef82e644d792edf98f7f350f928%2Fforms-delivery-and-retries-03-failed-row.png?alt=media" alt="Una fila Falló desplegada en el diálogo Historial del webhook mostrando 5 intentos, el cuerpo en Lo que enviamos y la respuesta en Lo que respondió HTTP 500"><figcaption><p>Una entrega que se rindió tras <strong>5 intentos</strong>. La transcripción sigue disponible.</p></figcaption></figure>

***

## Qué significan los estados

<figure><img src="https://365551146-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMUYDYzjmxpzlYaw0gcaZ%2Fuploads%2Fgit-blob-7afbba9012cca75e2d4fdc0ee7fb50886a4b8ab2%2Fforms-delivery-and-retries-01-history-statuses.png?alt=media" alt="El diálogo Historial del webhook listando filas Entregada, algunas con una insignia Prueba"><figcaption><p>Píldoras de estado y la insignia <strong>Prueba</strong> en un diálogo de historial.</p></figcaption></figure>

| Estado        | Qué significa                                                                                                                                                                                                                                                                                             | ¿Se reintenta?                                                             |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
| **Entregada** | 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.                                                       |
| **Falló**     | Reintentos agotados. La fila conserva el último mensaje de error y, en los webhooks, **Lo que respondió**.                                                                                                                                                                                                | No. Arregla el destino; la siguiente respuesta o **Enviar prueba** pasará. |
| **Omitida**   | No se hizo a propósito porque no podía aplicar (por ejemplo una sincronización de reserva en un formulario cuyo destino de HubSpot se apagó entretanto, o una reserva que la protección contra spam no pudo emparejar con una persona verificada). 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 del 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, con las horas en la zona horaria de tu workspace. 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, con las reservas listadas como `crm_update`; las de correo muestran qué aviso se envió, una fila por destinatario.

A nivel de cuenta, el inventario de **Webhooks** de la página de [Conexiones](/dapta-docs-es/dforms/connect/connections.md) muestra una columna de **Entrega** por formulario: vacía cuando está sano, o un **{n} sin entregar** 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.

<figure><img src="https://365551146-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FMUYDYzjmxpzlYaw0gcaZ%2Fuploads%2Fgit-blob-2573dd7dcb6c4fa7374d9bc0fabe4d55f9d73d50%2Fforms-delivery-and-retries-04-connections-delivery.png?alt=media" alt="La tabla de Webhooks de la página de Conexiones con una insignia roja de 4 sin entregar en la columna Entrega"><figcaption><p>El inventario marca los formularios cuyo webhook tiene entregas fallidas.</p></figcaption></figure>

***

## 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

* [Webhooks](/dapta-docs-es/dforms/connect/webhooks.md) y [Probar y ver el historial de entregas](/dapta-docs-es/dforms/connect/webhooks/test-and-history.md)
* [Cómo funciona la sincronización con HubSpot y solución de problemas](/dapta-docs-es/dforms/connect/hubspot/how-sync-works.md)
* [Correos de respuesta](/dapta-docs-es/dforms/connect/emails.md)
* [Solución de problemas](/dapta-docs-es/dforms/troubleshooting.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.dapta.ai/dapta-docs-es/dforms/connect/delivery-and-retries.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.