Do I need webhook deduplication if providers already say they retry safely?

Yes — you still generally need webhook deduplication.

“Safe retries” from providers usually means they will retry on failure without changing the event semantics, not that your system will only receive the webhook once. In practice, duplicates still happen because of:

• network timeouts after your server processed the request
• provider retry logic after non-2xx or ambiguous responses
• at-least-once delivery semantics
• race conditions / concurrent retries
• manual replay by the provider or support staff

What “safe retry” usually means

It typically means the provider:

• uses the same event ID on retries
• does not assume your first attempt succeeded unless it got a proper acknowledgment
• may resend the same payload multiple times

That’s great, but it still means your handler must be idempotent.

What you should do

Implement deduplication using one of:

• the provider’s unique event ID
• a stable composite key, like (provider, event_id)
• sometimes (object_id, event_type, created_at) if no event ID exists, though that’s weaker

Store processed IDs in a durable place, e.g.:

• database table with a unique constraint
• Redis with TTL if short-lived duplicates are acceptable
• message queue consumer dedup layer

Important distinction

• Deduplication prevents reprocessing the same webhook more than once.
• Idempotency ensures processing the same event twice has no bad effect.

Ideally, you want both.

Rule of thumb

If the webhook can:

• create orders
• send emails
• charge money
• update state

then duplicates can cause real damage, so deduplication is worth it even with “safe retries.”

If you want, I can show a simple dedup pattern for a webhook endpoint in your stack (Node, Python, Go, etc.).