A failed delivery is a queue problem, not a lost submission.

The order of operations that makes this simple

The submission is written first, then delivery is queued. Every recovery tool below depends on that order: because the record exists before anything is sent, a delivery failure is never also a data failure. Retrying is therefore always an operation on a stored object, never a request to a person.

Automatic retries

Up to five attempts, recording each response. The retry exists for the ordinary case: a mail provider rate-limits briefly, a receiver returns 503 while restarting, a network blips. Those clear on their own within a few attempts, and the log shows a gap of seconds followed by a success.

Five attempts does not fix a wrong secret, a dead hostname, or a handler that always throws. Those fail five times and then stop, which is the correct outcome: an unbounded retry loop against a broken receiver is noise that hides the real problem.

Manual retry, manual replay

Two different tools for two different channels, and mixing them up wastes time.

• Retry re-queues failed email channels attached to a submission. Use it after fixing a recipient, removing a suppression, or correcting a sending domain.
• Replay resends a specific webhook delivery. Use it after fixing your receiving endpoint.

curl -X POST https://freelyform.com/api/webhooks/deliveries/DELIVERY_ID/replay \
  -H "Authorization: Bearer <API_KEY>"

Design the receiver for repetition

Every delivery system that promises "at least once" forces the same decision on the receiver: be idempotent, or live with duplicates. Store the submission id from the payload, skip an event you have already processed, and return 2xx quickly. A handler that does slow work inline will time out, get retried, and double-process — which looks like a sender bug and is a receiver design problem.

When to leave it failed

If the receiver was deliberately removed, or the recipient asked to stop receiving mail, a failed delivery is the correct end state. Retrying into a suppression list or a decommissioned endpoint is how a good log turns into noise.