Give the next step a trigger.

What changes.

A webhook is an event notification sent from one service to another. A form submission, booking change, or payment event can tell your workflow that something happened without a person copying the details.

The receiver still has work to do. It needs to identify the event, verify it using the sending service’s supported method, and decide what action is appropriate. Treat incoming data as input to check, not an instruction to trust blindly.

Design for repeated and delayed events. The same event may be delivered more than once, and delivery rules vary by provider. A useful log should help the owner distinguish received, processing, completed, and failed work.

Receiving an event and completing the work are different states.

A practical example.

Put it in place.

Start with the smallest version you can inspect from beginning to end. Agree the process before connecting live business data.

1. 01

   Choose the event that should start the workflow.

2. 02

   Follow the provider’s instructions for a receiving endpoint.

3. 03

   Verify incoming events using the supported method.

4. 04

   Record an event identifier and processing status.

5. 05

   Accept work reliably before acknowledging it.

6. 06

   Keep repeated events from repeating the business action.

7. 07

   Test failure, recovery, and visibility for the owner.

Check the handoff.

• The event source is verified using the provider’s documented method.
• A repeated event can be recognized.
• The receiver acknowledges only work it has accepted reliably.
• Slow processing has a clear place to continue.
• Failed events can be investigated and recovered without blind retries.