Prevent duplicate runs with idempotency keys.
Learn how stable event IDs stop repeated webhooks from creating duplicate side effects.
Choose a stable key
Use a source event ID, form submission ID or a combination such as client ID plus reporting period. Avoid timestamps generated anew for each retry.
Persist the key
Store processed keys in a durable data store with a unique constraint. An in-memory variable is not sufficient across restarts or multiple workers.
Make side effects safe
Check the key before sending a message or creating a record, and persist completion status so concurrent deliveries cannot both proceed.
Handle partial failures
Store a run state such as started, completed or needs-review. Decide how a manual operator safely resumes an incomplete run.
Test replays
Send the same test event twice and concurrently. Verify one intended side effect, a visible duplicate outcome and no silent data loss.
Use the toolkit
Turn this advice into a structured workflow, then test it with synthetic data before production.