Paste one URL, and the workflow listens before it runs

A trigger used to mean a schedule or an integration the assistant subscribed to for you. That left out every service whose entire integration surface is a box asking for a webhook URL: a Framer form, a Typeform, a Zapier step, the script on somebody's server. There was nothing to subscribe to, so there was nothing to offer.

A workflow's trigger can be a webhook URL now. The assistant mints it during the interview and shows it in a card with a copy button, and the workspace keeps it on the Apps tab. It is the same URL for the life of the workflow. There is no test URL to swap for a production one at go-live, which is the way these usually break.

Before you publish, the URL answers nothing unless you open a two minute listen window, from the interview or from the test run panel. Send a real delivery through that window and it is captured into the payload library and pinned as the example the workflow is built against. So the steps get written against the fields the service really sends. After you publish, every delivery starts a run.

Beside the URL there is an auth token, generated for you and replaceable. Hand it to the other service as a custom header, as HTTP basic auth with the username all-agents, or as the secret it signs its deliveries with. Regenerating rotates the URL secret and the token together, and it is the only thing that changes the URL: publishing, pausing and publishing again leave a pasted URL alone.

Any method is accepted, and the workflow receives an envelope of method, query, headers, content_type and body, with the body parsed when it is JSON and kept as text when it is not. HEAD and OPTIONS on a live URL answer 200 so a service's test connection button gets the answer it is looking for. A page in a browser still cannot post to one of these, and is not going to be able to: the URL is the credential, and a URL a page can post to is a URL its readers can post to.