What Is a Webhook? A Plain-Language Guide for Workflow Planning

Identify the event and payload

An event might be a submitted form, a changed record, or a completed task. The payload is the information sent with that notification. Read the provider’s current documentation to learn the event name, fields, and delivery behavior.

For a fictional enquiry, the payload could include an enquiry ID, submission time, and message text. A field may be missing or have a different type than expected. Write a small input contract before mapping it directly to the destination.

Verify and validate before processing

Use the provider’s supported authentication or signature verification method. Keep secrets in the intended credential mechanism rather than in public instructions. An endpoint receiving a request does not by itself establish who sent it.

Check required fields and allowed event types. Route unexpected input to a controlled failure path. If the request contains private data, minimize logging and follow the relevant organizational rules. AI interpretation belongs after predictable validation, not in place of it.

Acknowledge and complete are different

The sender may treat a response as acknowledgment that the event was received. The downstream task may still be queued or fail later. Define how the workflow records received, processing, completed, and needs-review states.

Do not tell a customer that an action completed merely because the webhook arrived. Check the destination result. For long work, a queue can separate quick receipt from processing, depending on the platform’s supported design.

Plan delivery edge cases

Some services retry notifications, deliver events out of order, or delay delivery. Check the specific provider’s behavior. Use stable identifiers to prevent duplicate creates and compare version or event time where the task requires ordering.

Consider what happens when a notification never arrives. A reconciliation check may compare source records with completed destination records. The appropriate check depends on the importance of the task and the services involved.

Test the complete path

Use a provider-supported test event or fictional payload in an authorized environment. Confirm reception, validation, mapping, action, and logging. Then test a missing field and repeated event. A successful endpoint response is only one part of the evidence.

Keep the payload example and recovery steps in the workflow documentation. Read our repeat-action guide before connecting a webhook to automatic record creation.

Example: one event delivered twice

A form service sends the same enquiry event twice after it does not receive the expected acknowledgment. Both notifications carry the same source ID. The receiving workflow recognizes that reference and follows its repeat policy rather than creating two enquiries.

Check the service’s documented behavior before designing this test. Some providers have specific acknowledgment time limits and retry schedules. Keep those details with the workflow’s configuration rather than assuming every webhook service behaves alike.

A completion assumption to avoid

An HTTP success response can acknowledge receipt without proving that the downstream record was created. Check the workflow’s completion state and destination result separately.

Frequently asked questions