Summary

The Catch Webhook trigger gives any Alta Flow a unique HTTPS URL. Anything that can make an HTTP request — your CRM, your product backend, a Zapier or n8n flow, a third-party tool's "outgoing webhook" — can hit that URL with any method (GET, POST, PUT, DELETE, etc.) and the flow runs with the request payload as input. You can leave the endpoint open or lock it down with Basic Auth, a shared header, or full HMAC signature verification.

Who this is for

Anyone building a workflow that should run on demand from an external system — webhook deliveries from Stripe, HubSpot, Calendly, Typeform, GitHub, internal services, etc. Use this when you don't want to poll on a schedule and you don't have a native Alta integration to listen with.

Before you start

You can edit flows in Alta (Workflows section).
You know what the sender will POST — body shape, headers, and whether it signs its requests. The auth choice below depends on that.

Step 1 — Add the Catch Webhook trigger

Open a flow (or create a new one) in Workflows.
Add a trigger step and pick Webhook (it lives in the Core category — described as "Receive HTTP requests and trigger flows using unique URLs.").
Choose the Catch Webhook trigger.
Alta displays the Live URL — a unique HTTPS endpoint for this flow. Copy it; this is the URL your sender will call.

Step 2 — Pick an authentication mode

The trigger has a single Authentication dropdown with four options. Default is None.

None

The endpoint accepts every request that hits it. Use this only if the URL is treated as a secret and the caller can't sign requests. Anyone who learns the URL can trigger your flow.

Basic Auth

Standard HTTP Authorization: Basic header.

Username — required. The username the caller must send.
Password — required. The password the caller must send.

The caller base64-encodes username:password and sends Authorization: Basic <base64>. If the header is missing or doesn't decode to the exact pair, Alta drops the request and the flow doesn't run.

Header Auth

A single shared-secret header — simplest option for senders that can attach a custom header.

Header Name — required. The HTTP header to check (e.g. X-Webhook-Token).
Header Value — required. The exact value the caller must put in that header.

Header name match is case-insensitive; the value must match exactly. Mismatched value = no run.

HMAC Signature

The strongest option — the caller signs the raw request body with a shared secret and sends the signature in a header. Use this whenever the sender supports it (GitHub, Stripe, Shopify, Twilio, custom internal services). Alta recomputes the signature on its side and uses a timing-safe comparison.

Signature Header Name — required. The HTTP header the signature is in (e.g. X-Signature, X-Hub-Signature-256). Default: x-signature.
Secret — required. The shared secret used to compute the HMAC. Keep this out of version control.
Algorithm — required. SHA-256 (Recommended), SHA-1, or SHA-512. Default: SHA-256.
Signature Encoding — required. Hexadecimal or Base64. Default: Hexadecimal.
Signature Prefix — optional. The fixed prefix to strip before comparing (e.g. sha256= for GitHub webhooks). Leave empty if there's no prefix; if you set a prefix and the incoming header doesn't start with it, the request is rejected.

Step 3 — Send a test request and inspect the payload

From the trigger step, send a sample request to the Live URL using curl, Postman, or the sender's own "test webhook" button. Include any auth header you configured.
Alta records the incoming payload — body, headers, query — and exposes it as the trigger's output. Every downstream step can reference those fields via the variable picker.
Continue building the flow against the real payload shape (no guessing).

Step 4 — Publish the flow

Like any flow, the webhook URL is live as soon as you publish. Drafts won't run, even if requests arrive at the URL.

Tips and common pitfalls

HMAC checks keep failing. Three common causes: (1) the signature is computed over the raw body but the sender JSON-stringified it differently than Alta does — make sure the sender signs the exact bytes it sends. (2) Wrong algorithm or encoding. (3) A prefix mismatch — GitHub sends sha256=..., so set Signature Prefix to sha256=.
I see the request in my logs but the flow didn't run. Authentication probably failed — Alta silently drops unauthenticated requests so you don't accidentally process spoofed traffic. Double-check the header name and value, then resend.
The endpoint accepts any HTTP method. GET, POST, PUT, DELETE — anything. The method, path, headers, and body are all available to the flow.
Don't paste the Live URL into chat or share it externally. Without auth it's a public trigger. Use HMAC or Header Auth for anything that touches customer data.
Header name is case-insensitive on read, case-preserved on send. Header Auth normalizes the configured name before lookup, so X-Token and x-token match the same incoming header.
Rotating a secret? Edit the trigger, change the value, and republish — Alta uses the latest published config, so old requests with the old secret will start failing the moment the new version goes live. Update the sender first, then publish.