Webhooks do not promise exactly-once delivery

A form provider can retry. A person can submit twice. A timeout can happen after the receiving workflow completed its work but before the sender saw the response. If the intake flow assumes every delivery is unique, it can create duplicate lead records, messages, CRM entries, and reminders.

The most visible failure is sending the initial WhatsApp message twice.

Use business identity

An idempotency key should describe the business action, not a temporary workflow execution. A simplified shape is:

campaign + external submission + message role

That lets the system distinguish an action that was reserved, sent, completed, failed, or can safely be retried.

A lock is not durable idempotency

A short-lived lock can help with two simultaneous executions. It cannot prove that a message was already sent in a previous process, after a restart, or during a retry. Durable idempotency needs a persistent status record.

The useful pattern is a reservation followed by the irreversible action and a completion state. It also needs a recovery path: a reservation must not block a legitimate retry forever after a recoverable failure.

What I learned

Duplicate prevention should be designed around the customer-facing action. In lead intake, a clean log record matters, but avoiding a second message matters more.

What should happen next

I want a dedicated idempotency contract with documented atomic transitions and retry rules, whether it lives in a specialised store or a carefully constrained configuration database.