It is not.

It means: if the same event shows up twice, your workflow’s side effects happen once.

That matters the moment you add AI to a no-code stack.

Because AI steps are slow. Slow steps miss webhook timeouts. Missed timeouts cause retries. Retries re-run the whole scenario. And suddenly your “helpful” assistant sends two follow-ups, creates two CRM notes, or posts two Slack alerts for one invoice dispute.

This post is a practical pattern you can paste into Zapier, Make, or n8n without writing a full backend. No prices. No tool worship. Just the reliability habit most demos skip.

The failure mode in one story

Imagine a booking form posts to your webhook.

Your scenario:

1. Receives the payload
2. Asks an AI model to draft a confirmation email
3. Creates a CRM contact
4. Sends the email

Step 2 takes 12 seconds. The sender’s webhook client times out at 10 seconds and retries. Your platform starts a second run with the same payload.

Result:

• Two contacts (or a messy upsert race)
• Two emails
• One confused customer

Nothing “AI-specific” caused this. AI just made the window for retries wider.

What the platforms actually guarantee (verified)

Do not assume the automation tool will dedupe for you.

Zapier (official help):

• Polling triggers compare each item’s unique ID to IDs seen before and only run on new IDs (How Zapier handles duplicate data).
• Instant triggers do not use that deduplication, because Zapier’s docs treat them as “apps only send new data.”
• Actions follow the destination app: some create duplicates, some error, some update, some silently ignore.

Translation for builders: if your Zap is webhook/instant-driven and then creates records or sends messages, you still need your own duplicate gate for side effects.

Make (official webhook docs):

• Instant webhooks process requests as they arrive.
• Default is parallel execution; “Process data in order” makes Make wait for the previous run before starting the next (Make webhooks help).
• Ordered processing reduces races. It does not by itself mean “same event ID runs once.”
• Make’s own support guidance in the wild for duplicate webhook deliveries is: enable ordered processing, search a Data Store for the ID, and only continue if it is new (documented in vendor/community threads such as Square’s webhook duplicate discussion summarizing Make support’s steps).

n8n:

• No magic “ignore retries” switch on a generic Webhook node.
• Official-style templates show the durable pattern: validate payload → check a Data Table for eventId → claim/process → respond deterministically on duplicates (Handle reliable webhooks with HTTP Request and Data Table nodes).

The pattern: Claim before you mutate

Treat every customer-facing or write action as forbidden until the event is claimed.

Step A — Extract a stable event ID

Prefer IDs the source system already owns:

• Stripe: event.id (evt_…)
• Help desk: ticket id + “created” or message id
• Forms: submission id
• Email: Message-ID header when available

If the source sends no ID, create one deterministically from immutable fields, for example:

sha256(source + customer_email + submitted_at + amount)

Do not use now() or a random UUID as your only key if retries must collapse to one run.

Step B — Claim the ID first (before AI)

Write the claim before the slow AI step.

Minimum columns:

• event_id (unique)
• status (claimed | succeeded | failed)
• claimed_at
• workflow_name
• last_error (optional)

Logic:

1. Try to insert event_id with status claimed.
2. If insert fails because it already exists → stop (or return “already processed”).
3. If insert succeeds → continue to AI + actions.
4. On success → set status succeeded.
5. On terminal failure → set status failed (and decide whether a human can replay).

This is the same idea as INSERT … ON CONFLICT DO NOTHING in SQL, expressed with:

• Zapier: Storage / Tables / a small database app with a unique key
• Make: Data Store search → filter “not found” → add record
• n8n: Data Table or Postgres unique constraint

Step C — Make side effects safe even if claim races

If two runs start before either write lands (rare but real under parallel execution):

• Prefer a store with a unique constraint and treat conflict as “I lost the race.”
• Or turn on Make’s Process data in order for that scenario so runs serialize (Make webhooks help).
• Keep AI drafts in a draft state (CRM note, Gmail draft) until a human or a second gate sends.

Zapier’s trustworthy-agent guidance matches this instinct: separate draft from irreversible send, and require approval for customer-facing and hard-to-reverse actions (safe and trustworthy AI agents).

Worked example: invoice dispute intake

Canonical payload

{
  "event_id": "stripe_evt_1Qdispute_88421",
  "type": "invoice.dispute_opened",
  "customer_email": "alex@example.com",
  "invoice_id": "in_88421",
  "amount_cents": 18900,
  "currency": "usd",
  "received_at": "2026-10-22T11:02:04Z"
}

Scenario sketch

1. Webhook received
2. Normalize fields (do not let the model invent invoice_id)
3. Claim event_id in Data Store / Table
4. If duplicate → respond 200 “duplicate” and exit
5. AI step: produce JSON {summary, suggested_internal_note, risk: low|medium|high} with low temperature
6. Validate JSON schema in a Code / Tools step
7. Create internal ticket / CRM note with the draft
8. If risk is high → Slack human; do not email the customer automatically
9. Mark claim succeeded

Notice what is missing on purpose: auto-send to the customer on first build.

Zapier Tables claim recipe (no custom server)

If you are on Zapier and want a concrete claim step:

1. Create a Table webhook_claims with a text field event_id (treat it as unique in practice) plus status, claimed_at, zap_name.
2. Right after the trigger, Find Record where event_id equals your extracted id.
3. Path A — record found and status is succeeded or claimed: stop (or respond duplicate).
4. Path B — no record: Create Record with claimed, then continue to AI.
5. After successful side effects: Update Record to succeeded.
6. After terminal failure: failed, and decide whether a human replay Zap may run.

Remember Zapier’s own distinction: polling triggers already dedupe by unique id; instant triggers do not get that safety net (duplicate data help). Your Table is the safety net.

Also remember actions may still create duplicate CRM rows if the destination app allows it — claiming prevents your Zap from trying twice; it does not rewrite another app’s API semantics.

Make Data Store claim recipe

1. Scenario setting: enable Process data in order when retries overlap (webhooks help).
2. After the webhook: Data Store → Search records for event_id.
3. Filter: continue only when search returns zero bundles.
4. Add a record with event_id + claimed before the AI module.
5. AI → validate → mutate → update record to succeeded.

This mirrors what Make support has recommended when external systems appear to deliver duplicates under load: search, filter, store, then proceed.

AI makes idempotency harder — plan for it

Three AI-specific twists:

1. Latency: models expand the retry window. Claim before the model call.
2. Non-determinism: the second run may draft different text. That is fine if you never send twice; store prompt_version so you can explain score changes later.
3. Partial success: AI succeeds, email send fails, retry arrives. Your claim row must distinguish claimed vs succeeded, or a naive “ID exists → skip” will block a legitimate replay after a true failure.

A practical policy:

• Duplicate while succeeded → no-op
• Duplicate while claimed and younger than N minutes → treat as in-flight (no-op or wait)
• Duplicate while failed → allow a manual replay path only

Test plan you can run in an afternoon

1. Send the same webhook payload twice in 2 seconds.
2. Confirm one claim row and one customer-facing action.
3. Force the AI step to take > sender timeout (or mock a delay) and confirm retries do not double-send.
4. Kill the run after AI but before send; confirm status stays claimed/failed and your replay rules behave.
5. Change the prompt; confirm logs record prompt_v2 without resetting event IDs.

If step 1 already double-sends, do not add more AI features yet.

When not to obsess

• Pure internal logging with no customer impact
• Reads-only enrichment that is cheap and harmless to repeat
• Platforms where the trigger is polling with a stable unique ID and your actions are naturally upserts

Even then, once money, inbox, or deletes are involved, claim first.

Takeaways

• Idempotency = same event, one set of side effects.
• Official docs: Zapier dedupes polling triggers by ID; instant triggers are not covered by that mechanism; Make parallel webhooks need your own gate; n8n expects you to build it.
• Claim the event ID before slow AI steps.
• Separate drafts from sends.
• Test double-delivery on purpose.

Reliability is not the opposite of shipping fast. It is how your automation still looks smart on a bad network day.

If you are also thinking through the trust and access side of wiring AI into your stack, I wrote a plain-English companion on whether it is safe to connect your business apps to AI automation tools.