Zintara webhook duplicate handling without a stable event ID

Define the decision

The reviewed envelope includes event, data and a second-resolution timestamp, but no stable event ID. A lead can reply more than once with the same subject. Deduplicating forever by leadId or subject would discard legitimate activity.

Work through the procedure

1. Verify the raw-body signature before admitting the notification.
2. Store a receiver-generated receipt ID and raw-body digest for diagnostics.
3. Make state-setting actions, such as marking an address suppressed, safe to repeat.
4. For nonrepeatable actions, use reconciliation or manual review instead of a guessed uniqueness key.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Receipt A: reply.received, lead X, subject "Re: question"
Receipt B: another genuine reply from lead X with the same subject
Unsafe key: event + leadId + subject
Safer business action: update a review-needed state without creating an unbounded duplicate task

Read the result

A raw-body digest can identify identical received bytes, but it is not a provider-issued event identity and can still collapse indistinguishable events. Treat it as a bounded operational aid, not an exactly-once guarantee.

Check before moving on

1. Test two legitimate same-subject replies.
2. Test repeated delivery against each downstream side effect.

Limits and next action

If the business process requires exact event identity and complete replay, the current webhook contract needs additional support. Keep that requirement explicit before production adoption.

Source: Zintara product context