Skip to main content
HTTP triggers give a workflow a unique public endpoint. Choose the trigger based on the request shape you control: Open the trigger configuration to copy its endpoint. Treat this URL like an unguessable integration address: share it only with the systems that should start the workflow.

​
URL trigger

Use URL when you need control over the request method or body type. Its trigger data includes:
  • Path
  • Method
  • Headers
  • Query
  • Body
Header names are lowercase. Cookie, Cloudflare-prefixed, and forwarded-address headers are omitted. Query values are exposed as strings. Text bodies remain text; binary bodies are exposed as base64 text. The URL shown in the trigger panel can be opened directly for a quick GET test.

​
Webhook trigger

Use Webhook for an external service that sends a JSON POST. Its trigger data includes:
  • Data — the parsed JSON value,
  • Path,
  • Query, and
  • Headers.
Requests with another method receive 405 Method Not Allowed. Invalid JSON is rejected before the workflow receives trigger data.

​
Form Submission trigger

Use Form Submission as an HTML form’s target. A POST parses multipart form fields and files. Repeated field or file names may produce lists rather than single values. The trigger can also serve configured HTML on GET. When HTML Response is enabled, opening the endpoint returns that HTML and does not create a workflow run. A POST to the same endpoint still submits the form and starts the workflow. If the HTML response is disabled, a GET starts the workflow with its query parameters exposed as Fields.

​
Return a custom response

Add one response action to the branch that should answer the caller. Respond Text, Respond JSON, Respond Status, and Redirect are available for all three HTTP triggers. The browser-oriented Respond HTML, Respond File, and Close Window actions are intended for URL and Form Submission workflows. Connect every value that must be computed before the response. The HTTP request waits for a response-capable action when an enabled one exists anywhere in the run’s graph snapshot.
Only the first response action that executes can answer the request. If several response branches are eligible concurrently, their canvas position does not decide which wins. Make the branches mutually exclusive or route them into one response action.

​
Default response behavior

The caller receives different defaults depending on the saved graph: An action error does not automatically become an HTTP error response. A dependent response action may be skipped because the failed action produced no normal output, which leads to the generic completed-without-response result. Use Did Action Succeed? and Error to build an explicit error response branch. See Meta controls for that pattern.

​
Test the endpoint

Save the graph, enable the workflow, and send a representative request. For repeatable testing, keep an example curl command or request fixture with the method, headers, query, and body your integration actually sends. Then inspect both sides:
  1. Confirm the caller received the expected status, headers, and body.
  2. Open the workflow run and inspect Data from Trigger.
  3. Check any decoded object properties, files, or base64 body before passing them downstream.
Follow Testing workflows for the full edit-test loop and External triggers for other ways systems can start workflows.