EnglishWebhooksManual redelivery

Manual redelivery

Every webhook delivery is recorded for 60 days in the INFI dashboard. If your endpoint was down at the time of the original delivery, or if you need to reprocess an event, trigger a new attempt from the dashboard.

Where to resend

There are two paths:

1. Through the transaction (timeline)

In the dashboard: Payments → click on a transaction → drawer opens.

The “Sent webhooks” section shows each delivery triggered by that event, with:

  • Status (success, failure, pending).
  • HTTP status of the last attempt.
  • Number of attempts (including manual).
  • Date/time of the last attempt.
  • Resend button next to each row.

2. Through the dedicated page (global list)

In the dashboard: Webhooks → Delivery history.

Paginated list of all deliveries in the last 60 days. Filter by:

  • Status: success, failure, pending.
  • transactionId: paste the ID and search.

Each row has a details button that opens a side drawer with:

  • The exact payload that was sent (formatted JSON).
  • Full timeline of attempts (with manual: true on attempts you triggered).
  • Resend webhook button that triggers a new attempt.

Resend behavior

When you resend a delivery:

FieldWhat happens
eventIdPreserved — same evt_xxx as the original delivery. If you implement dedup by X-Infi-Event-Id, the resend attempt is treated as a duplicate (correct).
transactionId, status, eventIdentical to the original delivery.
timestampRegenerated for the moment of the resend. Clients that reject old timestamps (replay protection) accept it normally.
X-Infi-SignatureRecalculated with the new timestamp + body. Your HMAC validation works identically to the first send.
Target URLThe same URL configured in the original delivery. If the URL was removed since, the resend fails.
End-to-end idempotency

Use X-Infi-Event-Id (or eventId in the body) as the dedup key. Resending the same delivery 5 times results in 1 event processed on your side, with 4 idempotent retries. See Retry.

Limits

  • 10 resends per hour per account. Hard limit to avoid loops with a buggy integration.
  • Only deliveries from the last 60 days can be resent (history TTL).
  • Resend only fires for the original URL of the delivery. To send to another URL, edit your webhook in Webhooks → Configuration, and the next event will go to it (the original delivery stays in history).

Use cases

  • Endpoint was down: after it’s back, open the history filtered by failed and resend in order.
  • Bug in processing: fixed the handler, reopen the transaction and resend to reprocess.
  • Manual validation: want to see the exact payload that arrived? Open the delivery details — the JSON appears formatted on screen.
  • Platform migration: configured a new endpoint, validate with some resent deliveries before cutting over.

Operation response

The interface confirms each resend:

  • ✅ Resent (HTTP 200) — success, your endpoint replied 2xx.
  • ❌ Failed (HTTP 500) — endpoint replied with an error. Try again after fixing.
  • ❌ Failed (network error) — timeout, DNS, etc. Check the URL.
  • ❌ Resend limit reached — exceeded 10/h. Wait.

The new attempt is logged in the history with manual: true on the corresponding row — you can distinguish manual deliveries from automatic ones afterwards.

Retry and idempotencyTransaction limits