Test webhook automation: delivery and duplicate processing

A webhook reports an event to your receiver. The actual work follows: validate fields, retrieve additional data and possibly change something at the destination. Choose an event trigger in the integration selector if that matches your task. The checklist below proposes a test sequence for your own workflow. It does not promise exactly one delivery or automatic retries from every provider. Those properties belong to the documentation of the specific service.

Make three states visible

Give the test a fixed event identifier and an expected destination state. For a “create task” example, that means exactly one task with a specified title in a test project. Count destination objects before and after the run. Record the delivery identifier, processing status and target identifier together. A successful HTTP response alone cannot tell you whether the task is missing, exists twice or was created in the wrong project.

Validate origin and event type before acting

Follow the signature scheme documented by the provider. GitHub, for example, documents validation using X-Hub-Signature-256 and a shared secret; verification must match the unchanged request body. Do not assume the same scheme applies to another provider. Also check that the event type and action belong to your workflow. A correctly signed event with an irrelevant action should cause no destination change. Keep secret values out of URLs and test logs.

Repeated delivery must not create a second effect

In your own design, distinguish a delivery identifier from a business operation key. The former helps trace a delivery, while the latter identifies the intended change. Account for two simultaneous attempts as well: checking “not present yet” before writing is insufficient when runs overlap. Use the target’s documented idempotency feature where available. Otherwise, the workflow needs suitable persistent coordination and a way to reconcile the destination state.

GitHub retains the original X-GitHub-Delivery identifier when a redelivery is requested. That provides a concrete test case, but it is not a universal rule for webhook providers. Do not simply delete evidence of the first processing attempt when retrying. After a timeout, the target change may already have happened. Check the destination first; blindly writing again can create exactly the duplicate your test is meant to prevent.

A small but meaningful test matrix

1. Send a valid test event. Expect exactly one matching change and a traceable completion status.

2. Repeat the same event and also test two simultaneous attempts. The destination change must not happen twice.

3. Interrupt processing after acceptance. Check that the persisted job can resume afterwards.

4. Test an invalid signature, an unknown action and a missing required field. None should cause an unintended destination change.

GitHub does not automatically redeliver failed deliveries. Check its documented redelivery options and record who handles outstanding jobs. The n8n guide helps identify the connection direction; the workflow planner provides matching app steps. If periodic requests fit your service better, compare the approach with the API and webhook guide. Keep the acceptance record and the processing record separate enough that you can identify an interrupted job without treating it as a completed operation.

Does HTTP 200 mean the whole job is done?

Not necessarily. The response may confirm acceptance only. Check processing status and the destination result separately.

Are webhooks always retried automatically?

No. That depends on the provider. Check its retry policy and the procedure for requesting a redelivery.

What does idempotency mean here?

Repeating the same business operation creates no additional intended effect. The particular workflow still needs an appropriate implementation.

Should I test with real customer data?

A test project with known records is enough for these checks. It lets you inspect changes and repeated attempts completely.

1. GitHub webhook practices
   Show retrieval command

   curl -s https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks
2. GitHub delivery validation
   Show retrieval command

   curl -s https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries
3. GitHub webhook redelivery
   Show retrieval command

   curl -s https://docs.github.com/en/webhooks/testing-and-troubleshooting-webhooks/redelivering-webhooks

All posts