Webhook receiver

What this accomplishes

The webhook receiver is a local HTTP server that turns an inbound webhook into a workflow trigger. It only binds to 127.0.0.1 — it is never a public endpoint — and it can require an HMAC-SHA256 signature per path.

This page is the webhook receiver. The local scheduler is in local scheduler.

Current availability

This page documents behaviour verified in Miton development builds. Miton is still pre-release and is not publicly downloadable; invited beta users will receive a signed desktop build with automatic updates.

Before you start

• A Miton development build, an active project and Automation open.
• A connected model plus permission for every file, network or scheduled action in the workflow.

The loopback binding

The receiver binds to 127.0.0.1 only — it isn’t reachable from another machine on your network or from the internet. The default port is 7733; if that port is taken, it tries the next one up (within a small range) rather than failing to start. If you need a public endpoint, run your own reverse proxy in front of it — that proxy, and its security, are yours to manage.

Routes and payload

Every path under /hooks/ is a webhook target, so a workflow’s webhook trigger node can use any path you choose (for example /hooks/github-releases). The receiver passes the raw request body through to the workflow trigger as-is, whatever format it’s in.

HMAC authentication

Set a secret for a path, and the receiver requires every request to that path to carry a valid X-Hub-Signature-256 header — the same header GitHub webhooks use — an HMAC-SHA256 of the raw request body, hex-encoded, in the form sha256=<hex>. A missing or invalid signature is rejected with 401.

A path with no secret set accepts unsigned requests. Set a secret for any webhook trigger that matters — the receiver doesn’t require one by default.

To rotate a secret, set a new one for the path; the previous value stops being accepted immediately. There’s no dual-secret grace period — update the sending system at the same time you rotate.

What the webhook receiver does not cover

• Public webhook endpoints — you’d need your own reverse proxy; the receiver itself never listens on anything but loopback.
• Replay protection — the signature covers the body, not a timestamp, so there’s no built-in rejection of an old, otherwise-valid signed request being resent.
• Authentication schemes other than HMAC-SHA256 — no OAuth, no API keys, at the receiver level.

What success looks like

An external system posts to your webhook path, the signature checks out, and the matching workflow’s webhook trigger fires — without opening anything to the public internet.

Common failures and recovery

• A 401 usually means the sending system’s secret doesn’t match what you set for that path, or it’s signing with the wrong header.
• Confirm credentials, permissions and test fixtures belong to the active project.
• Use a dry run to isolate a misconfigured node before starting the complete workflow again.

Related next action

Open the Automation overview to connect this task to the rest of the workflow.