Safely resume failed automation: design idempotency keys and an execution ledger

FROM PRIMARY SOURCES

Read the validity period and matching-content rules

Resend's current documentation describes checking the same email idempotency key within the previous 24 hours. It distinguishes a reused key with different content from another request with the same key still in progress.[1] This is a specification for the relevant Resend APIs, not a guarantee applicable to every external service.

Its implementation article describes normalising and hashing the request body and associating it with the response.[2] We refer to these as existing materials checked on 1 November 2026, not a new announcement. The execution ledger and stopping conditions below are editorial design proposals.

Sources: [1][2]

EDITORIAL PRACTICE

Separate business-operation identity from attempt numbers

First define what counts as the same work. For one approved notification to one destination, for example, associate the business event, destination and content version. This is a design example; the article does not send notifications. A key derived only from each execution time can make a retry look like new work. Use an identifier that leads back to the original business operation.

Conversely, treating a corrected notification as the same operation may suppress a necessary send. Record corrections as new versions and retain their relationship to the original. Check the external API's key retention period and scope as well: creating an application identifier alone does not establish that external duplication is prevented.

EDITORIAL PRACTICE

Do not classify unknown outcomes as failures

The execution ledger should retain the business-operation identifier, content version, attempt time, current state and external receipt ID. Do not return an operation to “unattempted” merely because communication stopped. Distinguish interruption before the request from a missing response after submission. For the latter, investigate saved receipts or external lookup methods before submitting another action.

The table below illustrates separate states. Some external services do not offer result lookup, so define a human investigation route for that situation too. A key requirement for recovery is that a new owner taking over does not reinterpret a request without a response as a confirmed failure.

EDITORIAL PRACTICE

Give retries a reason and a limit

Do not repeat temporary communication failures, missing permissions and invalid inputs on the same schedule. Review the external API specification and record which responses permit retries and which states require investigation first. When retrying the same operation, preserve its original key and content; do not bypass an unresolved outcome by inventing a new key.

Define attempt limits, waiting periods, permitted execution times and cumulative spending caps in advance. Stop at the limit and record the reason and next owner. Recovery should not involve suddenly increasing concurrency or removing cost controls to catch up. Handle expired work separately rather than automatically consuming the following day's capacity for new work.

EDITORIAL PRACTICE

Request evidence of recovery without duplicate outcomes

In a test environment, exercise interruption before an action, timeout after submission and duplicate arrival of the same request. Read back the number of business results saved, as well as the number of external requests. Use authorised test destinations or environments instead of sending trial notifications to production users, and keep trial records separate from ordinary results.

Report the stopping point, correction, read-back result and remaining uncertainty together. Starting a retry alone does not establish recovery. A shared ledger can reduce the client's need to reread logs and decide the resume point each time, while making careless resubmission of unknown outcomes easier to prevent.