Webhook

The Webhook trigger runs a workflow whenever an inbound HTTP request reaches a URL Sim generates for it. Use it to start a workflow from any external service or custom app that can send an HTTP request — when no dedicated integration trigger exists.

Webhook

Webhook URL-

Require Authentication-

Input Format-

How it works

Add the Webhook trigger as the workflow's entry point.
Copy the unique webhook URL Sim generates.
Point your external service at it with a POST.
Every request to the URL runs the workflow, with the request payload available downstream.

Configuration

Input Format

Optionally define the JSON shape you expect. The fields are documented on the block and read downstream by name. Use a file[] field for uploads.

Authentication

Turn on Require Authentication and set a token. Callers send it as a Bearer token in the Authorization header, or you name a custom header (like X-Secret-Key) and the token is matched against that instead.

Response

By default the endpoint acknowledges receipt. Switch to a custom response to return your own status code and JSON body to the caller.

Outputs

The request is parsed and made available to the rest of the workflow — the body's fields by name (a userId in the body reads as <webhook.userId>), plus the request headers and query parameters. Common fields like event, id, and data are pulled out of the payload when present.

Behavior

Deduplication — idempotency checks prevent duplicate runs from repeated identical requests.
Rate limiting — built-in protection against abuse.
Deploy required — the URL only fires once the workflow is deployed; otherwise it returns not-found.
No auto-disable — unlike polling triggers (RSS, Gmail, IMAP), a push webhook processes each request independently and doesn't disable itself after failed runs.

Validate and sanitize incoming webhook data before you use it downstream.

Test it

Send a request to the webhook URL with curl (or Postman) and watch the run appear in Logs:

curl -X POST "<your webhook URL>" \
  -H "Content-Type: application/json" \
  -d '{"event": "test", "userId": "123"}'

Open the run to confirm the payload landed the way downstream blocks expect — that <webhook.userId> resolves, and that authentication rejects a request without the token if you turned it on.

Service triggers

Many integrations can act as triggers too: toggle Use as Trigger on a service block (Slack, GitHub, Stripe, and more) to register a service-specific webhook with event filtering and structured data — no generic endpoint to wire up.

See Triggers for every service that supports this.

Common Questions

POST triggers workflows. GET is used only for provider-specific verification challenges (such as Microsoft Graph or WhatsApp). Other methods return 405 Method Not Allowed.

Enable Require Authentication and set an Authentication Token. Callers send it as a Bearer token in the Authorization header, or you specify a custom header name (e.g. X-Secret-Key) and the token is matched against that header.

Yes. The Input Format field lets you define the expected JSON schema. It's optional but documents the structure, and you can use a file[] field for uploads.

Yes. The processing pipeline includes idempotency checks that prevent duplicate runs from repeated requests with the same payload.

All of it — headers, body, and query parameters are parsed and available to downstream blocks. Common fields like event, id, and data are extracted from the payload when present.

Yes. The endpoint checks that the workflow is deployed before triggering a run; otherwise it returns a not-found response.

No. Unlike polling-based triggers (RSS, Gmail, IMAP), push-based webhooks don't auto-disable — each request is processed independently. If runs fail consistently, check the run logs.

Webhook

Common Questions

On this page