Triggers

Every way to start a workflow - manual, webhook, schedule, hosted form, Google Form, Stripe, and workflow-failure - and what each one puts in the run context.

Every workflow starts with exactly one trigger node. This page covers what ships today; see Workflows for how the context each one writes gets used downstream, and the Triggers category in the node reference for the one-line version of each.

Manual trigger

Labeled "When clicking 'Execute workflow'" on the canvas. Click the Execute workflow button in the editor toolbar to run the workflow on demand with a sample payload - the fastest way to build and test a graph before wiring it to something live.

Webhook trigger

Gives the workflow a unique URL: /api/webhooks/wf/[workflowId], guarded by a per-workflow secret. The node's dialog shows the URL and secret with copy buttons and a regenerate-secret action.

Send a POST with the secret in either the x-webhook-secret header or a ?secret= query parameter:

curl -X POST "https://pipory.com/api/webhooks/wf/<workflowId>?secret=<secret>" \
  -H "Content-Type: application/json" \
  -d '{"email": "ada@example.com"}'

A missing or wrong secret returns 401. On success, the parsed JSON body becomes available downstream as {{webhook.x}} for any field x in the body.

If the workflow contains a Webhook Response node, the route waits (up to 10 seconds) for that node to run and returns its templated status code and body synchronously - so a webhook-triggered workflow can behave like a request/response API. Without one, the route returns 202 immediately with the execution id.

Trigger filters. The Webhook (and Schedule) trigger dialog can carry AND/OR condition groups evaluated against the incoming payload before an execution is created. A request that doesn't match is acknowledged with 200 { filtered: true } and spawns no execution - useful for noisy webhooks where you only care about a subset of events.

Schedule trigger

Runs on a cron expression and timezone, for example */5 * * * * for every five minutes. A single minutely Inngest cron checks every workflow's due schedules and fans out, so editing the cron expression doesn't require re-registering anything. An enable/disable toggle stops future runs without deleting the trigger.

Google Form trigger

Fires when a linked Google Form is submitted. The response is available downstream as {{googleForm.x}}, with formId, formTitle, responseId, respondentEmail, responses, and the raw payload under raw.

Stripe trigger

Fires on a Stripe webhook event (a payment, a subscription change, and so on). The event is available downstream as {{stripe.x}}, with eventId, eventType, timestamp, livemode, and the event's data object under raw.

Form trigger

Publishes a hosted public form at /f/[workflowId]. Declare fields in the node's dialog - text, textarea, number, select, or checkbox, each optionally required - and Pipory renders them as a public page with your title, description, and submit button text. A submission fires the workflow with the values available downstream as {{form.x}}, and shows your configured thank-you message. Submissions are rate-limited per IP (10 per rolling 60-second window) and only known field keys are accepted.

From the editor, a Run with inputs dialog lets you test a form-triggered workflow with the same fields without going through the public page.

On Workflow Failure trigger

A workflow whose trigger is On Workflow Failure doesn't run on its own - it runs when another workflow fails. Configure it to watch a specific set of workflows or all of them. When a watched workflow's execution ends in FAILED, this monitor workflow fires with the failure available downstream as {{failure.x}}: workflowId, workflowName, executionId, error, and (when known) errorStack and failedNodeId. Build your own alerting on top of it with any normal action node - Slack, Discord, Email.

Polling triggers

A polling trigger framework runs on a configurable interval and fires the workflow once per new item - for services whose APIs don't support outgoing webhooks. Polling triggers include:

Gmail: New Email, Google Sheets: New Row, Google Drive: New File, Google Calendar: New Event, Google Forms: New Response (all via Google OAuth credential)
Airtable: New Record, Notion Database: Page Added, HubSpot: New Contact, HubSpot: New Deal, Typeform: New Response, Cal.com: New Booking, Tally: New Submission (via each app's API key)
GitHub: New Issue, Linear: New Issue, Shopify: New Order, IMAP: New Email, RSS Feed

Each polling trigger shows up in the Trigger History tab alongside webhook and schedule events.

Chat trigger

Publishes a hosted chat widget at /chat/[token] where a visitor can type a message; each message fires the workflow with {{chat.message}}, {{chat.chatSessionId}}, and {{chat.timestamp}}. Pair it with a Webhook Response node to send a reply back to the same widget - use the AI Agent node to generate the reply. Requires the workflow to have been Published at least once.

Rolling out

Mailhook (inbound email) trigger - a unique inbound email address per workflow that fires it with the parsed subject, body, and attachments - is on the roadmap, held pending inbound-email routing.

Workflows - how the context each trigger writes gets templated downstream.
Executions - where to see exactly what payload a trigger received.

On this page