Automate · Triggers

Start workflows with webhooks

A webhook gives one deployed workflow an opaque HTTP endpoint. Configure accepted methods, authentication, and response behavior in YAML or override them for one environment in the app.

Last reviewed July 14, 2026

In the app Projects → project → Webhooks

Problems this solves

Start with the recurring problem, then use this feature when its boundary matches the outcome you need.

Problem

Turn an inbound event into durable work

A source system can make an HTTP request but cannot run a multi-step business process itself.

How this helps

Give one workflow an opaque Webhook URL, verify the sender, and let SolidActions record and resume the resulting run.

See a minimal webhook workflow →

Problem

Acknowledge quickly, finish later

The sender needs a fast response while the actual processing may take longer or wait on other work.

How this helps

Choose instant response behavior, or use an early workflow response when the caller needs a calculated acknowledgement.

See the early-response pattern →

Enable a webhook

Declare it before deploying:

workflows:
  - id: receive-order
    file: src/receive-order.ts
    trigger: webhook
    webhook:
      method: POST
      auth: hmac
      response: instant

A workflow without a YAML webhook can also be enabled from the Webhooks tab. SolidActions generates an opaque token URL and a signing secret. Copy the URL only to the sender that needs it.

Choose authentication

HMAC (default): The sender signs the request body with SHA-256 and the webhook secret. SolidActions accepts the supported signature headers and rejects a missing or invalid signature.
Basic Auth: The sender provides the configured username and password.
API Key Header: The sender puts the webhook secret in the configured header, such as X-API-Key.
None: Anyone who knows the URL can trigger the workflow. The app requires an explicit public-webhook confirmation.

Treat the URL and secret as credentials.

Keep them out of source, screenshots, tickets, and chat transcripts. If either is exposed, edit the webhook secret and update the sender. A secret change breaks old signatures immediately.

Choose response behavior

Instant response

SolidActions accepts the request and lets the workflow continue in the background. You can choose a 2xx status and a JSON response body using {{trigger_id}}, {{run_uuid}}, and{{timestamp}} template values.

Wait for result

The HTTP request remains open while the workflow runs, up to the configured timeout. A completed workflow returns its output; a failure returns an error response; an expired wait returns a timeout even though the run may still be visible in SolidActions.

Override and reset configuration

Open the Webhooks tab in the exact project environment.
Select the edit action and change methods, auth, or response behavior.
Save the override. It persists across later deploys and takes priority over YAML.
Use Reset to defaults to return to YAML, or to platform defaults when YAML has none.

The status chip identifies a YAML default, an app override, or a platform default. Keeping that source visible prevents a later YAML edit from being mistaken for the active setting.

Call and inspect the webhook

curl --request POST 'WEBHOOK_URL' \
  --header 'Content-Type: application/json' \
  --data '{"orderId":"ord_123"}'

Add the authentication expected by your configuration. Then open Runs and filter to the workflow. The trigger column identifies webhook/API activity and the run detail preserves its input.

List endpoints from the CLI

solidactions webhook list my-project -e production
solidactions webhook secret my-project -e production --workflow receive-order

Use secret-revealing commands only in a trusted terminal and never paste their output into support messages.

Next: compare scheduled triggers or diagnose the execution inRuns.