## 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.

```text
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