> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# Entrega, reintentos y fallos
> Verifique webhooks, configure reintentos y trate envoltorios de fallos.
Una notificación genera un registro de entrega por cada suscripción confirmada cuyo filtro coincida. Los reintentos actualizan ese registro. Haga el procesamiento idempotente, por ejemplo guardando el ID de la notificación junto a la operación completada.
## Envoltorios de webhook y entrega directa
El cuerpo HTTP predeterminado es un envoltorio JSON con `type: "notification"`, `message_id`, `topic_crn`, `topic_name`, `subscription_id`, `message`, `timestamp` y `unsubscribe_url`. Asunto y atributos aparecen cuando se proporcionan. `message` sigue siendo una cadena aunque contenga JSON.
Con `raw_message_delivery: true`, el cuerpo contiene el contenido seleccionado. Los metadatos quedan en los encabezados `X-Basaltic-Notification-Type`, `X-Basaltic-Message-Id`, `X-Basaltic-Subscription-Id`, `X-Basaltic-Topic-Crn`, `X-Basaltic-Unsubscribe-Url` y `X-Basaltic-Delivery-Attempt`. El tipo sigue siendo `application/json`; elija contenido adecuado.
Las colas siempre reciben el envoltorio e incluyen identificadores de la notificación en los atributos. Para FIFO, Notifications deriva el grupo del CRN del tema y la deduplicación del ID del mensaje publicado. El orden FIFO se aplica dentro de la cola; la distribución asíncrona no garantiza el orden de publicación.
## Verificar firmas de webhook
Toda solicitud de webhook firmada incluye:
```text theme={null}
X-Basaltic-Signature: v1,t=,s=
```
Use los bytes UTF-8 literales del secreto como clave HMAC. Los bytes firmados son timestamp, punto y cuerpo bruto exacto. No interprete y vuelva a serializar el JSON antes de verificar. Compare en tiempo constante y rechace timestamps más de cinco minutos en el pasado o futuro. Verificar la firma no sustituye la deduplicación de reintentos válidos.
La misma verificación se aplica a `subscription_confirmation`. Después, el propietario puede seguir `confirm_url` para consentir. Responder correctamente a la solicitud inicial solo confirma su recepción.
No almacene el secreto en registros. La lectura y rotación exigen permisos separados. La rotación sustituye la clave; coordínela con el operador del destino. Describir o listar suscripciones nunca devuelve el secreto.
## Política de reintentos
| Campo | Valor predeterminado | Intervalo | Significado |
| - | - | - | - |
| `max_attempts` | 6 | 1–10 | Total de intentos, incluido el primero. 1 desactiva reintentos. |
| `min_delay_seconds` | 20 | 1–3,600 | Espera inicial antes de reintentar. |
| `max_delay_seconds` | 1,200 | 1–3,600 | Límite de espera exponencial antes de la variación aleatoria. |
| `timeout_seconds` | 15 | 1–30 | Timeout por intento de webhook; se ignora en email. |
La suscripción sustituye el tema por campo. Los valores no especificados usan los predeterminados de la plataforma. La espera se duplica entre intentos e incluye variación aleatoria; son límites y valores predeterminados, no horarios exactos. Cuando se indican ambos retrasos, el máximo no puede ser menor que el mínimo.
En webhooks, HTTP `2xx` significa éxito. Timeouts, fallos de conexión, HTTP `408`, `429` y `5xx` pueden generar reintentos. Otros `4xx` y todos los `3xx` son definitivos; no hay redirección. Un destino que resuelve a una dirección privada bloqueada también falla definitivamente. El éxito HTTP no prueba que se completara la operación de negocio.
## Colas de mensajes no entregados
Defina `redrive_policy.dead_letter_queue` en la suscripción para guardar un envoltorio tras un fallo definitivo. La cola puede ser estándar o FIFO en la misma cuenta y región. Configurarla exige `queue:SendMessage`.
El envoltorio incluye la notificación original, ID de suscripción y entrega, intentos, hora y último error. El registro sigue fallido tras redirigir. Los destinos llenos, eliminados o no disponibles pueden impedir el almacenamiento; supervise los fallos y la cola, sin tratarla como una segunda garantía de entrega.
Esto trata fallos al entregar al destino. Para un consumidor que recibe pero no procesa un mensaje ya encolado, configure la [política de redirección](/es/queue/fifo-and-dead-letter-queues) de la cola de destino.
## Diagnosticar una notificación ausente
1. Confirme la aceptación de la publicación e inspeccione la distribución.
2. Compruebe si la suscripción está confirmada.
3. Compare los atributos con toda la política de filtro.
4. Localice la entrega y examine intentos y último error.
5. En webhooks, compruebe URL, firma y estado HTTP.
6. En colas, compruebe disponibilidad, clave de cifrado y concesiones de consumidores.
Use las [métricas Telemetry](/es/notifications#metrics) para tendencias y alertas. Las suscripciones filtradas no tienen intento de entrega fallido. Las muestras ausentes indican un hueco de observación, no ausencia demostrada de entregas.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.