Define one intended message before choosing modules
A duplicate is two deliveries of the same intended message, not simply two webhook requests. A registration event and a reminder event may legitimately concern the same subscriber. Our proposed design uses a key such as workshop-42:registration-803:reminder-24h:v1. The registration identifier distinguishes recipients; the reminder type distinguishes legitimate messages; the version changes only when you intentionally create a different message.
Use the originating application's stable event or registration identifier. A new timestamp generated on every attempt defeats deduplication because every retry gets a new identity. Do not put email addresses, webhook secrets, or message bodies into a shared diagnostic worksheet. Keep the actual recipient lookup in the access-controlled system that already owns that data.
Use a delivery ledger with explicit states
This ledger is an implementation design, not a tested Make template. Choose storage whose concurrency guarantees you understand. Checking for an absent key and then inserting it are two operations; concurrent workers can both pass the check. A database unique constraint or atomic claim can prevent that race. A simple data-store lookup should not be described as equivalent without verifying its behavior.
| State | Meaning | Next action |
|---|---|---|
| Pending | Intended message exists; no attempt claimed | Claim the key before sending |
| Sending | A worker owns an attempt | Other workers wait; inspect stale attempts |
| Accepted | Provider acknowledged a message ID | Store the ID; suppress another send |
| Unknown | Timeout or interrupted write after sending | Check provider records before retry |
| Failed | Definite rejection; no acceptance | Correct cause and apply a bounded retry |
| Cancelled | Reminder no longer appropriate | Do not send |
Separate execution recovery from delivery proof
Make documents parallel processing for instant webhooks and an option for sequential processing. Serializing the scenario helps when two arrivals overlap inside that scenario. It does not serialize an independent scenario, stop the upstream system from sending the event again later, or prove that a remote email operation happened only once.
Make also documents incomplete executions and retry handling. Review where a resumed execution starts and which earlier modules already succeeded before resolving it. An automation run marked successful is evidence about the workflow, while a provider message ID is evidence of acceptance by the email service. Neither proves inbox placement or that the recipient read the message.
Work through the difficult timeout case
Hypothetical example: attempt A claims the reminder key at 09:00. The email service accepts it, but the connection closes before Make receives the response. At 09:01 the original registration webhook arrives again. The ledger still says Sending. Sending another email immediately could produce a duplicate; marking it Accepted without evidence could hide a missing reminder.
Move the attempt to Unknown after your documented timeout boundary. Look for the original request reference or provider message record. If the service supports an idempotency key for this exact endpoint, follow its documentation and retention window. If it does not, there may be no fully automatic way to distinguish accepted from lost. Put uncertain cases into a review queue with an owner and a deadline. Expiring a lock alone is not permission to resend.
Run five failure tests with a controlled recipient
Use a dedicated test recipient and synthetic registration data. Agree on the expected result before running each case. Repeat a failure case after a design change, and retain actual results separately from this proposed checklist. We have not run these five scenarios against a production email provider.
| Test | Expected behavior | Evidence to retain |
|---|---|---|
| Same webhook twice in sequence | One accepted send for the key | Two arrival IDs; one provider message ID |
| Same webhook twice concurrently | Only one worker claims the message | Claim results and provider records |
| Definite provider rejection | No accepted state; bounded retry after correction | Rejection code and attempt count |
| Timeout after possible acceptance | Unknown state; no blind resend | Reconciliation decision and reviewer |
| Registration cancelled before reminder | Cancelled state blocks send | Cancellation time and suppressed attempt |
Set operating limits before switching on
- Name the owner of Unknown and Failed states and define how quickly each must be reviewed.
- Cap retries and define the latest useful send time; a workshop reminder sent after the workshop is not recovered value.
- Keep the deduplication record longer than the upstream retry window and your own replay period, subject to your data-retention policy.
- Monitor intended reminders, accepted sends, suppressed duplicates, and unresolved attempts separately.
- Use the downloadable ledger to record the test result and evidence reference for each case. A blank evidence field means the case is unverified.
Watch demos / Official walkthroughs
See how the tools work.
Videos load from YouTube only when you press play. These are provider videos, not our own product tests.
Make / Official video
Make—Building Your First Automated Workflow from Scratch
What to look for: Follow how modules connect and how data moves through the first workflow.
Watch on YouTubeYour next step / Review the option
Make
A visual tool to investigate small workflow designs, beginning with synthetic data and human review.
Free plan includes 1,000 credits/month
Connected apps can cost extra. Free scheduled interval is at least 15 minutes; paid billing must be checked at checkout.
Affiliate link: we may earn a commission on an eligible purchase. Link disclosure
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- Make: webhook processing and queues Accessed 2026-09-13
- Make: incomplete executions Accessed 2026-09-13
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.