Idempotent endpoints are safe to retry. PUT /resource/42 with the same body twice is the same as once: the resource ends up in that state. POST /transfers with $100 from A to B twice is NOT idempotent — without an idempotency key, it transfers $200.
Webhook handlers must be idempotent. Providers retry on 5xx, network blips, their own internal failures. Your handler will see the same event-id more than once. Keep a table of processed event-ids; if the inbound event is already there, return 200 without re-processing.
Stripe popularized the Idempotency-Key request header for client-side calls — you generate a UUID per logical operation, Stripe deduplicates server-side. Same idea, applied to outbound API calls instead of webhooks.