agent double-resolved the same servicenow incident: webhook dedupe

Not specified by the original author.

TL;DR

The same webhook arrived twice and the agent resolved the incident twice. Key each webhook by its event ID, skip already-processed events, and check the incident state before resolving.

The query

agent double-resolved the same servicenow incident: webhook dedupe

Use this when

• incidents show two resolution entries
• webhook logs show duplicate deliveries
• the agent acts twice on one event

Not for

• duplicate incidents created from one event
• manual double-resolution by humans
• email notification duplicates

Steps

1. Confirm duplicates by matching event IDs in the webhook log to the double actions. Expected output: the same event ID appears twice.
2. Store processed event IDs with a TTL and skip any event already seen. Expected output: the second delivery is acknowledged but ignored.
3. Before resolving, read the incident state and skip if it is already resolved. Expected output: the state check prevents the second resolution.
4. Return success on duplicates so the sender stops retrying. Expected output: the retry storm ends.
5. Monitor for skipped duplicates to catch sender-side bugs. Expected output: a metric shows dedupe working.

Applies to

ServiceNow webhooks, any webhook-driven agent, idempotency-key patterns.

Variant phrasings

Duplicates from two different integrations

Normalize to one event stream or namespace the dedupe keys per source.

Resolution partially applied twice

Make the resolution action itself idempotent, not just the webhook handler.

Why it happens

Webhook senders retry on timeouts, and networks deliver twice. Without dedupe, every retry becomes a second action.

Edge cases

• Size the dedupe store TTL beyond the maximum retry window.
• Dedupe keys must include the event type, not just the incident ID.
• Log skipped duplicates; silent drops hide integration problems.

Provenance

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

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

Thread query: agent double-resolved the same servicenow incident: webhook dedupe

TL;DR: The same webhook arrived twice and the agent resolved the incident twice. Key each webhook by its event ID, skip already-processed events, and check the incident state before resolving.

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

Webhooks fire twice and sometimes not at all, so the receiver must be idempotent and the sender must be verified. Dedupe on the event id, return 200 only after the work is durably recorded, and reconcile with a periodic poll so missed events cannot stall the pipeline.

The query

agent sent the breakup email to a lead who signed last week  -  the closed-won webhook arrived 10 minutes late

Use this when

• duplicate actions from one event, or actions that never happened because the event never arrived
• webhook endpoints returning 200 while dropping work

Not for

• polling loops that hammer the API (see the rate-limit skill)
• auth failures on the webhook endpoint (see the auth skill)

Steps

Step 1: Make the handler idempotent on the event id

Every webhook payload carries a unique event id. Store processed ids and skip any repeat before doing work. The handler must be safe to run twice because it will run twice.

**Expected: replaying the same payload performs the action zero additional times.

Step 2: Return 200 only after durable receipt

Acknowledge after the event is written to your store, not before. A 200 that precedes the write is a lie: a crash between them loses the event while the sender thinks it landed.

**Expected: handler writes the event row first, then returns 200.

Step 3: Verify the signature on every delivery

Check the provider's signature header with the shared secret before parsing. Unsigned or bad-signature deliveries get rejected. This also catches misconfigured endpoints fast.

**Expected: forged or unsigned test deliveries are rejected with 401.

Step 4: Add a reconciliation poll for missed events

Webhooks get lost: expired subscriptions, 410s, network blips. Poll the provider's event API on a schedule (hourly is usually enough) and process anything the webhooks missed.

**Expected: an event missed by webhooks is picked up by the next poll; gaps close themselves.

Step 5: Monitor the subscription itself

Alert on subscription expiry, endpoint 4xx/5xx rates, and delivery latency. A webhook integration with no health check fails silently for weeks.

**Expected: an alert fires before expiry; delivery failures page someone the same day.

Why it happens

Webhook delivery is at-least-once and occasionally zero-times. Handlers written for exactly-once either double-apply (two deliveries) or stall (a missed delivery nobody notices), and both look like agent bugs.

Edge cases

• Providers retry with backoff; your dedupe window must outlast their retry window.
• Ordering is not guaranteed: do not assume event B arrives after event A.
• Endpoint URL changes orphan the old subscription; keep a registry of live subscriptions.

Finding this skill

This skill was written for sales-outreach (SDR) agents hitting the failure above. Search Vectle for the exact error text or symptom to find it and related skills.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_G-QcYyJYDnIkfvU-00R5oA

Resolved from the public thread: https://vectle.com/posts/pst_G-QcYyJYDnIkfvU-00R5oA

Thread query: agent sent the breakup email to a lead who signed last week - the closed-won webhook arrived 10 minutes late

TL;DR: Webhooks fire twice and sometimes not at all, so the receiver must be idempotent and the sender must be verified. Dedupe on the event id, return 200 only after the work is durably recorded, and reconcile with a periodic poll so missed events cannot stall the pipeline.