Reenvío manual
Cada entrega de webhook queda registrada por 60 días en el panel de INFI. Si tu endpoint estaba caído en el momento de la entrega original, o necesitas reprocesar un evento, dispara un nuevo intento desde el panel.
Dónde reenviar
Hay dos caminos:
1. Por la transacción (timeline)
En el panel: Pagos → haz clic en una transacción → se abre el drawer.
La sección “Webhooks enviados” muestra cada entrega disparada por ese evento, con:
- Estado (éxito, falla, pendiente).
- HTTP status del último intento.
- Cantidad de intentos (incluyendo manuales).
- Fecha/hora del último intento.
- Botón reenviar al lado de cada fila.
2. Por la página dedicada (lista global)
En el panel: Webhooks → Historial de entregas.
Lista paginada de todas las entregas de los últimos 60 días. Filtros por:
- Estado: éxito, falla, pendiente.
- transactionId: pega el ID y busca.
Cada fila tiene un botón detalles que abre un drawer lateral con:
- El payload exacto que se envió (JSON formateado).
- Timeline completo de intentos (con
manual: trueen los intentos disparados por ti). - Botón Reenviar webhook que dispara un nuevo intento.
Comportamiento del reenvío
Cuando reenvías una entrega:
| Campo | Qué ocurre |
|---|---|
eventId | Preservado — mismo evt_xxx que la entrega original. Si implementas dedup por X-Infi-Event-Id, el intento de reenvío se trata como duplicado (correcto). |
transactionId, status, event | Idénticos a la entrega original. |
timestamp | Regenerado al momento del reenvío. Los clientes que rechazan timestamps antiguos (replay-protection) lo aceptan normalmente. |
X-Infi-Signature | Recalculada con el nuevo timestamp + body. Tu validación HMAC funciona igual que el primer envío. |
| URL destino | La misma URL configurada en la entrega original. Si la URL fue quitada desde entonces, el reenvío falla. |
Usa X-Infi-Event-Id (o eventId del body) como clave de dedup. Reenviar 5 veces la misma entrega resulta en 1 evento procesado en tu lado, con 4 reintentos idempotentes. Ver Reintento.
Límites
- 10 reenvíos por hora por cuenta. Límite duro para evitar loops con integración bugada.
- Solo entregas de los últimos 60 días pueden reenviarse (TTL del historial).
- El reenvío solo dispara a la URL original de la entrega. Para mandarla a otra URL, edita tu webhook en Webhooks → Configuración y el próximo evento irá a ella (la entrega original sigue en el historial).
Casos de uso
- Endpoint caído: tras volver, abre el historial filtrado por
failedy reenvía en orden. - Bug en el procesamiento: corregiste el handler, reabre la transacción y reenvía para reprocesar.
- Validación manual: ¿quieres ver el payload exacto que llegó? Abre los detalles de la entrega — el JSON aparece formateado en pantalla.
- Migración de plataforma: configuraste un nuevo endpoint, valida con algunas entregas reenviadas antes de cortar.
Respuesta de la operación
La interfaz confirma cada reenvío:
- ✅
Reenviado (HTTP 200)— éxito, tu endpoint respondió 2xx. - ❌
Falló (HTTP 500)— el endpoint respondió error. Intenta de nuevo tras corregir. - ❌
Falló (error de red)— timeout, DNS, etc. Verifica la URL. - ❌
Límite de reenvíos alcanzado— pasó de 10/h. Espera.
El nuevo intento se registra en el historial con manual: true en la fila correspondiente — puedes distinguir entregas manuales de automáticas después.