Do I need webhook retries if the other system also has retries?

Usually, yes — you should still have webhook retries on your side, even if the receiving system also retries.

Why:

• Retries solve different failure points.

  • Their retries help if they receive your webhook but fail to process it.
  • Your retries help if your delivery attempt fails due to network errors, timeouts, DNS issues, transient 5xxs, etc.

• A retry on only one side isn’t enough.

  • If your first delivery never reaches them, their retry logic never gets triggered.
  • If they receive it but your system thinks it failed because of a timeout, you may need to retry cautiously.

• Webhooks are usually at-least-once delivery.

  • That means duplicates can happen.
  • Both sides should be idempotent and able to handle repeated events safely.

What to do instead:

• Use short, bounded retries on your side with exponential backoff.
• Include a unique event ID so the receiver can dedupe.
• Make processing idempotent on both sides.
• Agree on timeouts, status codes, and retry behavior.

A good rule:

• Sender retries for delivery failures
• Receiver retries for processing failures
• Both must handle duplicates

If you want, I can also sketch a recommended webhook retry pattern and status-code contract.