> ## Documentation Index
> Fetch the complete documentation index at: https://docs.workflowmachine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Use webhooks

> Use webhook triggers to start workflows from external systems and custom events.

## Why webhooks are useful

Webhooks are one of the most flexible ways to start a workflow.

They let another system send data directly into Workflow Machine, which makes them useful when:

* you are integrating with a custom app
* you need an event-driven trigger from another system
* there is no native app trigger for the source

## When to choose a webhook

Use a webhook when the natural shape of the process is:

`Something happens elsewhere, and that system sends data into this workflow.`

Typical webhook use cases include:

* form submissions from external tools
* internal app events
* service-to-service notifications
* custom operational systems

## Design the payload carefully

The more predictable the incoming webhook data is, the easier the rest of the workflow becomes.

When planning a webhook workflow, decide:

* which fields are always present
* which fields are optional
* what downstream steps actually need
* what shape later steps expect

Good payload design reduces troubleshooting later.

## Keep webhook usage secure

Because webhooks accept external input, be deliberate about who can send data and what the workflow does with that data.

Good habits include:

* sending only the fields you need
* avoiding overly broad payloads
* being careful with sensitive data
* treating the webhook URL like a credential

Even when the workflow goal is simple, the input path should still be handled carefully.

## Test webhook payloads early

Webhook workflows should be tested as soon as the trigger and first downstream steps exist.

Testing should confirm:

* the webhook reaches the workflow
* the payload shape matches expectations
* downstream steps can use the incoming data correctly

Webhook issues are usually easiest to fix at the input stage, before the workflow grows more complex.

## Common webhook mistakes

Watch for these problems:

* assuming fields will always be present
* sending more payload data than the workflow really needs
* skipping payload testing before adding several downstream steps
* treating a webhook like a generic solution when a native app trigger would be clearer

The better the incoming payload is defined, the more reliable the workflow becomes.

## A good first webhook workflow

If you want a simple first webhook workflow, start with:

* one webhook trigger
* one small processing step
* one visible output such as Slack or Google Sheets

That gives you a fast feedback loop without too much moving complexity.