# Reintentos y logs

> Cuándo Rapid intenta entregar el webhook de nuevo, en qué intervalos, qué cuenta como éxito y cómo leer el log de entregas.

Página: https://doc.rapidchargeback.com/es/canais/webhook/retries-e-logs/

## Política de reintentos

Si tu aplicación responde con cualquier código distinto de `2xx`, o no responde dentro del timeout, Rapid considera el intento como fallido y vuelve a enviar el webhook.

Son **4 intentos** en total: el inicial y 3 más, cada uno esperando más que el anterior.

1. **En el momento** 1.er intento, apenas el evento entra en la cola
2. **+5 min** 2.º intento, 5 minutos después de la falla anterior (5 minutos desde el inicio)
3. **+15 min** 3.er intento (20 minutos desde el inicio)
4. **+30 min** 4.º y último intento (50 minutos desde el inicio)

Si el 4.º también falla, la entrega se cierra y la alerta queda disponible en el panel para acción manual (ver [Reenvío manual](#reenvío-manual)).

## Timeout

Cada intento tiene un **timeout de 30 segundos**. Si tu aplicación no responde en ese plazo, el intento se considera fallido.

## Qué cuenta como éxito

Cualquier código **`2xx`**: `200`, `201`, `202`, `204` y los demás del rango. El cuerpo de la respuesta es opcional.

Cualquier otro código (incluidos `4xx` y `5xx`) dispara un reintento.

### Redirección

Registra la **URL final**. Rapid trata las redirecciones así:

| Respuesta de tu URL | Qué pasa |
|---|---|
| `301`, `302`, `303` | **Falla.** Estos códigos cambian el POST por `GET` y descartan el cuerpo, así que seguirlos sería no entregar nada. El intento entra en el flujo de reintentos y el log muestra hacia dónde redirige tu URL. |
| `307`, `308` al **mismo** dominio | Se sigue, con el POST, el cuerpo y los headers intactos. Hasta 3 redirecciones seguidas. |
| `307`, `308` a **otro** dominio | **Falla.** El payload firmado no sale del dominio que registraste. |

Los casos comunes son que el servidor agregue `/` al final de la ruta y que cambie de dominio, como de `ejemplo.com` a `www.ejemplo.com` (que cuenta como otro dominio). En el log de entregas, el motivo empieza con `[redirecionamento]`, junto con la dirección de destino.

## Dirección que no es pública

Si la dirección registrada no resuelve a una dirección pública de internet (apunta a una red local o privada, o el dominio no existe), la entrega **falla sin ninguna solicitud** y entra en el flujo normal de reintentos. En el log de entregas, el motivo empieza con `[destino]`. Corrige la URL o el DNS del dominio; ver [Usa una dirección pública de internet](https://doc.rapidchargeback.com/es/canais/webhook/boas-praticas/#usa-una-dirección-pública-de-internet).

Si el motivo empieza con `[https]`, la URL registrada no usa HTTPS y Rapid no entrega en texto plano: registra una URL `https://`.

Si el motivo empieza con `[assinatura]`, la falla es del lado de Rapid: la entrega no sale sin firma, y se reintenta automáticamente. No hace falta hacer nada en tu sistema.

## Empresas bloqueadas

Si la empresa está bloqueada por falta de pago en Rapid, **el flujo de webhooks sigue normal**: las alertas se siguen recibiendo de los proveedores, guardando y entregando a la URL configurada. El panel sigue disponible. Lo que el bloqueo corta es la **API por credencial** (lectura y escritura: `GET/PATCH /chargeback-alert/alerts`, transacciones, merchants, alias heredados), que pasa a responder `403 COMPANY_BLOCKED`, y la defensa de nuevas disputas.

Para dejar de recibir alertas nuevas, hay que desactivar el registro directamente en el proveedor (acción que realiza el equipo de Rapid).

## Logs de entrega

Cada intento se registra internamente con:
- Evento entregado (`chargeback_alert.received`, `dispute.fraud.revoke_access`)
- Fecha y hora del intento
- URL de destino
- Código HTTP de la respuesta
- Cuerpo de la respuesta (truncado en 1000 caracteres)
- Número del intento

Ves estos registros en el panel de Rapid en dos lugares: en **Configuración › Webhook**, en el **Historial de entregas**, las entregas más recientes; en **Actividad**, pestaña **Webhooks**, el historial completo para depurar fallas. Cuando la falla no llegó a tu servidor, el panel muestra una explicación del motivo; el texto original, que empieza con `[https]`, `[destino]`, `[redirecionamento]` o `[assinatura]`, aparece al pasar el mouse.

## Reenvío manual

Cuando todos los intentos automáticos fallan, la alerta sigue en el panel. Para enviarla de nuevo, usa el botón **Reintentar** en el **Historial de entregas**, en **Configuración › Webhook**. La entrega reenviada llega como un webhook nuevo con el mismo `alert_id`, por eso la [idempotencia](https://doc.rapidchargeback.com/es/canais/webhook/boas-praticas/#idempotencia) es esencial.

El reenvío desde el panel vale para alertas. El evento `dispute.fraud.revoke_access` no tiene reenvío manual.