Every event from anywhere
lands where it should

Any service that can send a webhook can fire a workflow. Well known providers GitHub for code, Stripe for payments, Slack for messaging, GitLab for repos, Shopify for stores, Facebook for social are covered with native flows that handle the provider's specific format. Everything else is supported through the generic receiver, which accepts payloads of any shape and exposes them as variables to downstream nodes.

When a source sends a webhook, it attaches a signature computed from the payload and a shared secret known to both sides. The platform recomputes the signature with the same secret and rejects the request if values do not match. Fake events from somebody who guessed the address get rejected, and only genuine requests reach the workflow. The check happens automatically with no configuration for native providers.

Native providers handle the format specifics of well known sources out of the box. The platform knows GitHub uses a specific signature header, Stripe uses a different format, Slack expects a response within a tight window. Picking the native provider means the platform already knows the signature format, payload shape, event categories, and ack requirements so setup is minutes of configuration rather than hours of reading docs.

The unique address appears in the trigger configuration panel as soon as you choose webhook as the trigger type. A copy button puts it on the clipboard in one click. Paste it into the external source's webhook settings, save, and the workflow is wired. The address is unguessable, scoped to that workflow, and never reused so isolation is clean from day one.

Every event lands with the metadata you need timestamp, source address, complete payload, request headers, signature verification status, workflow run ID, and outcome. Searchable by any field, filterable by status, source, or date range, and retained for the lifetime of the workspace so compliance reviews and post incident analysis stop being archaeology.

Yes. Every event in the log has a one click replay action that re fires the workflow with the same payload that originally arrived. Useful for re running an event that hit a transient error, testing a workflow change against a real production payload, or walking a teammate through an exact scenario. Sample payloads are also available for native providers, so you can test end to end before any real event arrives.