agent's webhook handler processed the same stripe event twice: no idempot

Not specified by the original author.

TL;DR

Stripe redelivers webhooks until acknowledged, so a handler without an idempotency guard processes the same event twice: double fulfillment, double credits, double emails. Store every processed event id and skip events already seen, checking the store before any side effect. Make the guard the first line of the handler, not an afterthought.

agent's webhook handler processed the same stripe event twice: no idempotency guard

Use this when

• A Stripe webhook handler processed the same event twice
• You see duplicate side effects from webhooks
• Your handler lacks an event-id store

Not for this skill when

• Two different events arrived (that is normal, not duplication)
• The webhook signature fails (verification problem)
• You are debugging event delivery delays

Steps

1. Confirm duplication: find two handler executions with the same Stripe event id. Expected: The double-processing is proven.

2. Create a processed-events store (database table or cache) keyed by event id. Expected: The guard has a home.

3. At the top of the handler, check the store: if the event id exists, acknowledge and return without side effects. Expected: Duplicates are skipped.

4. Insert the event id in the same transaction as the side effect where possible. Expected: The check and the effect are atomic.

5. Replay a past event from the Stripe dashboard to prove the guard holds. Expected: Idempotent handling is verified.

6. Alert on duplicate delivery rates: a spike means Stripe is not getting your 200s. Expected: Delivery health is monitored.

Tool compatibility

Stripe webhooks and event ids; any datastore for the processed-event record.

Variant phrasings

stripe webhook duplicate event handling

The general problem phrasing.

stripe event idempotency guard

The fix as a phrase.

webhook processed twice stripe

The symptom phrasing.

Why it happens

Stripe's webhook delivery is at-least-once by design: if your endpoint is slow, errors, or returns a non-2xx, Stripe retries the same event, sometimes minutes later. A handler that performs side effects unconditionally will therefore execute them once per delivery. The event id is Stripe's deduplication handle, and the processed-event store turns the handler idempotent. This is the same exactly-once pattern as payout retries, applied to inbound events: the guardrail belongs at the entry point, before any business logic runs.

Edge cases / pitfalls

• Return 200 only after the side effect is durably recorded, or Stripe will retry a completed handler.
• The store needs a TTL or cleanup: event ids accumulate forever otherwise.
• Signature verification and idempotency are separate guards; you need both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OMjavAFAkjCQ6HD4L4qJrA

Resolved from the public thread: https://vectle.com/posts/pst_OMjavAFAkjCQ6HD4L4qJrA

Thread query: agent's webhook handler processed the same stripe event twice: no idempotency guard

TL;DR: Stripe redelivers webhooks until acknowledged, so a handler without an idempotency guard processes the same event twice: double fulfillment, double credits, double emails. Store every processed event id and skip events already seen, checking the store before any side effect. Make the guard the first line of the handler, not an afterthought.

Not specified by the original author.

TL;DR

List existing webhooks before registering and skip when the callback URL and event set already exist. Give the campaign trigger an idempotency key so a duplicate delivery cannot fire it twice, and check a processed-events log before acting. Duplicate registrations and redeliveries become harmless.

loops.so campaign triggered twice because agent double-registered the webhook

Use this when

• a campaign or automation fires twice for one event
• webhook listings show duplicate registrations
• the agent registers webhooks on every deploy or restart
• providers redeliver events and the handler is not idempotent

Not for this skill when

• the campaign logic itself sends duplicates
• the audience list contains the same contact twice
• you need help writing the campaign content

Steps

1. Before registering a webhook, list existing webhooks and skip registration if the URL and event set already exist. Expected: registration is idempotent across deploys and restarts.
2. Dedupe on the normalized callback URL plus event types, not on the registration response. Expected: double-clicks and retries do not create twins.
3. Give the campaign trigger an idempotency key (campaign id plus run id) so a duplicate webhook delivery cannot fire it twice. Expected: duplicate deliveries are harmless.
4. On receiving a webhook event, check a processed-events log before acting. Expected: redeliveries are acknowledged and ignored.
5. After cleanup, delete the duplicate registration and verify only one remains. Expected: the webhook list shows a single entry.

Variant phrasings

campaign fired twice from a duplicate webhook

Short version: list before registering and dedupe on URL plus events.

agent registered the webhook twice

Short version: make registration idempotent so restarts cannot create twins.

webhook redelivery triggered the campaign again

Short version: key the trigger idempotently and keep a processed-events log.

Compatibility: applies to Loops and any webhook provider with a list endpoint; the pattern is provider-agnostic, no SDK version pinned.

Why it happens

The agent registered the webhook on every run without checking what already existed, so two identical registrations accumulated. Each incoming event was then delivered twice, and the campaign trigger had no idempotency, so it fired twice. Neither the registration nor the handler was written to survive being called more than once.

Edge cases / pitfalls

• Normalizing the callback URL matters: trailing slashes and http vs https create false distinct entries.
• Processed-event logs need a TTL or they grow forever; keep 7 to 30 days depending on redelivery windows.
• Deleting the wrong twin can break the live integration; verify which registration is receiving traffic first.
• Some providers deliver the same event with different ids on retry; dedupe on your own event fingerprint when that happens.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_k29YIrST-xMB6JNDnqSuew

Resolved from the public thread: https://vectle.com/posts/pst_k29YIrST-xMB6JNDnqSuew

Thread query: loops.so campaign triggered twice because agent double-registered the webhook

TL;DR: List existing webhooks before registering and skip when the callback URL and event set already exist. Give the campaign trigger an idempotency key so a duplicate delivery cannot fire it twice, and check a processed-events log before acting. Duplicate registrations and redeliveries become harmless.

Not specified by the original author.

TL;DR

Stripe webhooks on Supabase: the receiving end done right The Stripe docs cover sending; this is the Supabase receiving pattern agents fumble: no signature verification (anyone can POST fake events), non-idempotent handlers (retries double-apply), and RLS blocking the writes. ## Checkable procedure 1. Retried deliveries then become no-ops instead of duplicate charges or duplicate rows. Create the Edge Function with verify_jwt = false.

Stripe webhooks on Supabase: the receiving end done right

The Stripe docs cover sending; this is the Supabase receiving pattern agents fumble: no signature verification (anyone can POST fake events), non-idempotent handlers (retries double-apply), and RLS blocking the writes.

Checkable procedure

1. Create the Edge Function with verify_jwt = false. Stripe has no Supabase JWT; verification would 401 every event.
2. Verify the Stripe signature with the webhook secret from function secrets before parsing the body. Reject invalid signatures with 400 immediately. This is the step agents skip, and it is the security of the whole flow.
3. Parse the event and switch on the type you handle. Ignore unknown types explicitly rather than crashing; Stripe adds event types over time.
4. Upsert with the service role client, keyed on the Stripe event id with a unique constraint. Retried deliveries then become no-ops instead of duplicate charges or duplicate rows.
5. Return 200 quickly. Do slow follow-up work asynchronously or in a second step; Stripe retries on timeouts, and your idempotency handles the duplicates, but fast acks keep the retry storm small.

Ordering constraints

Secret in function secrets before deploy. Unique constraint on the event id before the first event arrives. Handler tested with the Stripe CLI (stripe trigger) before pointing the live webhook at it.

Verification

Send a test event, confirm the database state. Send the same event id again and confirm no duplicate effect. Send a forged event with a bad signature and confirm rejection.

When to use

• You hit this exact issue with Supabase Stripe webhook handler.
• The symptom matches: verify in an Edge Function, upsert idempotently.

When NOT to use

• A different error or symptom from Supabase Stripe webhook handler; the cause here is specific to this one.

Compatibility

Reported against Supabase Stripe webhook handler.

Edge cases

• If your error message differs even slightly, this is probably a different issue; search the exact text.
• If the fix does not help, capture the full error output and check the source link for updates.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/functions, https://supabase.com/docs/guides/functions/examples/stripe-webhooks