Practical guides

Make website webhooks and integrations reliable

An integration needs more than receipt of a notification. It must distinguish valid events, duplicates, delays and interrupted processing to avoid repeating business operations.

Go to the method

One event, one operation

Write the event contract

Document the producer, expected event types, required fields and triggered operation. Describe results for creation, change and deletion where applicable. A notification should not implicitly authorise every possible action.

Choose a tracking identifier and an authoritative source to consult when uncertain. Describe how failures at the producer or receiver are detected. Integration documentation holds rules and owners; secrets belong in the project’s secure mechanism.

Verify before triggering an operation

GitHub documents delivery signature validation using the configured secret and received payload. Follow the actual provider’s documented mechanism; headers, algorithms and formats should not be copied from another service by analogy.

Separate origin verification, schema validation and operation authorisation. Test altered content, an unexpected event type and a missing field. Business processing should begin only after the controls required for the use case.

Plan repeats and interruptions

Define idempotent handling: a recognised repeated delivery should not create two orders or two final notifications. Test repetition before, during and after processing and an interruption between steps. The mechanism depends on the operation and storage involved.

Check the provider’s ordering and redelivery guarantees rather than assuming immediate, one-time arrival. Keep a queue of work requiring review and a way to reconcile it with the source. A positive technical response should correspond to a defined processing state.

Arrange monitoring and recovery

Record an event identifier, state and useful error while minimising data. Define who monitors failures, how authorised events are retried and how retries avoid duplicating completed work.

Interrupt the receiver in a test environment and restore it. Check catch-up and reconcile expected business results. Deliver an event contract, test batch, processing history and recovery procedure that the team can use.

Primary documentation : GitHub — Validating webhook deliveries.

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

Test cases, expected outcomes and useful evidence
CaseExpected outcomeEvidence to retain
Valid deliveryThe allowed event triggers an expected action that can be traced.Delivery identifier, processing result and resulting business state in the test system.
Changed body or invalid signatureBusiness processing never begins for the refused event.Observed refusal using a fully synthetic notification and test-only verification material.
Same delivery received twiceRepetition creates no unwanted additional business operation.Number and identifiers of recorded operations after both controlled attempts.
Delayed or reversed eventsThe ordering rule prevents older information replacing a newer state.Controlled chronology and documented final state, including any ordering limitations.

Frequently asked questions

Why send the same event more than once in a test?

To ensure a repetition does not trigger duplicate business operations. Providers may support or produce redelivery; receivers need to understand the rules and retain appropriate processing state.

Is a valid signature sufficient?

It contributes to origin and integrity checks according to the mechanism used. Event type, required data, permitted actions and processing state still need checking before a business operation.