Stripe resend keeps auto-retries; Sume redeliver uses no attempt

Stripe's manual resend does not stop automatic retries, even if the resend gets a 2xx. Sume's Redeliver is built around the opposite worry: it still works after all ten automatic attempts are used, and it does not consume one of them. In both systems you must dedupe, because a resend can arrive next to a retry.

Side by side

Stripe says you can resend from the Dashboard for up to 15 days after the event was created, or with the CLI for up to 30 days. It also says resending an event that had earlier failures does not dismiss the automatic retry behaviour, and points to a separate page on processing undelivered events to stop future retries. For Sume the docs give no age limit on Redeliver, but they do say the destination URL does not change.

What this means for a receiver

A Sume Redeliver carries a new timestamp, so a timestamp-based dedupe will treat it as new. Use the stable id instead: job_id for jobs, request_id (the run id) for Format runs. The run webhooks page repeats that rule for redelivery.

There is one more detail on Format runs. If a redeliver fails for a call whose earlier delivery already succeeded, the delivery row keeps the earlier 2xx and only counts the failed attempt in manual_redeliveries. So a green row can hide a recent failed resend.

• Redeliver needs jobs:write for jobs and formats:write for Format runs.
• 409 webhook_not_configured means the call never had a webhook URL.
• 409 run_not_terminal means the run is still going, so there is nothing to resend yet.

When to use which

Reach for Redeliver after you fix a bug in your handler, once the automatic attempts have run out. If the run or job is still pending, wait. If you only need the data, you do not need a webhook at all: read the result from status_url or result_url.

Operator runbook

After an outage, list the deliveries that failed, fix the receiver, and redeliver them one at a time while watching for duplicates. On Sume, check the delivery row for the final status code of each redeliver, since the redelivery object in the response reports delivered, status_code and error for that single POST.

Keep your own log of ids you have already processed. Both vendors can send the same event twice, once automatically and once by hand, and only your dedupe table makes that harmless. For Stripe the identifier is the event id, and Stripe notes that two separate event objects can occasionally describe the same thing, so it also suggests the object id plus type for those cases.