Implementation worksheet · 2 min read
How to test duplicate webhooks before launching an app
Test a duplicate webhook by delivering the same synthetic event more than once and checking the business outcome. The receiver should authenticate the event, record a stable deduplication key and apply the intended change once. Also test a crash between recording receipt and completing the action.
An AI-built subscription app may receive a payment event after a timeout or provider retry. A second delivery should not create a second entitlement, receipt or reward. Use your provider's test mode and documented replay mechanism; delivery semantics differ between providers.
Put it into practice
1. Identify the business effect
Choose one effect, such as granting access to a paid workspace. Write the expected entitlement before testing. Keep a delivery attempt identifier separate from the provider event identifier and business object identifier.
2. Send one event twice
Deliver the identical test event twice in sequence. Compare the event log, entitlement and any downstream message. The second attempt may be acknowledged successfully while doing no additional business work.
3. Test concurrent attempts
Replay the same event at nearly the same time. A read-then-write check without an atomic constraint can allow both attempts through. Use the datastore's supported uniqueness or transaction mechanism to enforce the invariant.
4. Interrupt processing
Simulate failure after the receipt is stored but before the entitlement is granted. A permanent ‘seen’ flag must not cause the retry to skip unfinished work. Track processing state and a recoverable completion boundary.
5. Test ordering separately
Send a later state before an earlier state. Decide whether to fetch the authoritative object or apply a version rule. Deduplication alone does not protect against valid events arriving out of order.
Replay scenarios
Copy this structure into your review document and record your observed result for each row.
| Input | Business effect | Review |
|---|---|---|
| First valid event | One entitlement change | Persisted state |
| Same event repeated | No extra change | Dedupe record |
| Concurrent repeat | One committed change | Atomicity |
| Crash before completion | Work resumes safely | Recovery state |
| Invalid signature | No business effect | Rejection log |
A failure worth checking
Returning a success response before work is durably queued can lose the action if the process exits. Conversely, keeping the HTTP request open for slow work can cause retries. Define a durable queue boundary and acknowledge according to the provider's documented requirements.
Common questions
Can I use the request timestamp as the key?
Usually not: a new delivery attempt can have a different timestamp. Use the provider's documented event identity and your business uniqueness rules.
Should every replay return an error?
No. A safely recognized duplicate can be acknowledged without repeating the side effect.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.