Triggers

Triggers define when and how a workflow executes. Every workflow can have one or more triggers, and each trigger type gives you a different way to start an execution — from an HTTP request, a cron schedule, a form submission, or an external event.

Webhook Triggers

Webhook triggers turn your workflow into an API endpoint. QuickFlo generates a unique URL that accepts HTTP requests — when a request comes in, the workflow executes with the request data as input and can return a fully customizable HTTP response.

This means you can build complete REST APIs, webhook receivers, and backend services entirely inside QuickFlo.

Configuration

Field	Description
Name	Human-readable identifier — also used as the URL slug (e.g., query-leads becomes https://run.quickflo.app/w/...query-leads)
Method	HTTP method the endpoint accepts — GET, POST, PUT, PATCH, or DELETE
Authentication	When enabled, generates a Webhook Secret — callers must include it as a Bearer token in the Authorization header or as a ?token= query parameter
Expose Errors	When enabled, error details from failed executions are returned in the HTTP response instead of a generic error

Accessing Request Data

The full HTTP request is available in your workflow via {{ initial.* }}:

{{ initial.name }}                         // body field
{{ initial.webhook.query.page }}           // query parameter
{{ initial.webhook.headers['x-api-key'] }} // request header
{{ initial.webhook.body }}                 // raw request body
{{ initial.webhook.files }}                // uploaded files (multipart)

For JSON request bodies, all top-level fields are spread directly onto initial for convenience. See Template Syntax — Webhook Triggers for the full reference.

Returning Responses

By default, webhook-triggered workflows run asynchronously — the caller receives a 202 Accepted response with an executionId immediately. To return a custom response, add a Return step to your workflow. QuickFlo detects this automatically and switches to synchronous execution so the caller waits for the result.

The Return step’s Webhook Response tab lets you configure the status code, response type, and body. QuickFlo supports three response formats:

JSON Response

Return structured JSON data with key-value pairs. Use template expressions to include data from any step in the workflow.

Field	Description
Status Code	HTTP status code (200, 201, 400, 500, etc.)
Response Body	Key-value pairs — each key becomes a JSON field in the response

Raw Response (XML, Text, HTML)

Return raw text content with a custom Content-Type. Perfect for XML APIs, plain text responses, HTML pages, or any non-JSON format.

Field	Description
Content-Type	MIME type for the response (e.g., application/xml, text/plain, text/html)
Response Body	Raw text content — supports template expressions

File Response

Return binary file content for downloads. The caller’s browser receives a file download prompt with the filename you specify.

Field	Description
MIME Type	File content type (e.g., application/pdf, text/csv, application/octet-stream)
File Content (Base64)	Base64-encoded file data — reference a step output containing the file content
Filename	The download filename (e.g., report.pdf) — sets the Content-Disposition header

Tip

You can use webhooks to build full API services — a GET endpoint that queries a database and returns JSON, a POST endpoint that processes data and returns a PDF, or an XML endpoint for telephony integrations like Twilio. The workflow is the backend.

Example: Building a REST API

# Query an endpoint that returns JSON
curl https://run.quickflo.app/w/@QMnb/query-leads \
  -H "Authorization: Bearer <secret>" \
  -H "Content-Type: application/json" \
  -d '{"region": "US", "limit": 10}'

# Response (from the Return step):
# {
#   "slots": [...],
#   "next_available": "2026-02-20T09:00:00Z"
# }

---

Scheduled Triggers

Schedule triggers run workflows automatically on a recurring basis using cron expressions. Use them for periodic data syncs, report generation, cleanup tasks, or any automation that runs on a timer.

Configuration

Field	Description
Name	Human-readable identifier (e.g., daily-6am-est)
Cron Expression	Standard 5-field cron syntax — minute, hour, day-of-month, month, day-of-week
Environment	Which environment to use when the schedule fires (loads that environment’s variables and connections)
Initial Data	Optional JSON object passed as {{ initial.* }} to the workflow on each execution

Cron Expression Examples

Expression	Schedule
0 6 * * *	Every day at 6:00 AM (UTC)
0 9 * * 1-5	Weekdays at 9:00 AM
*/15 * * * *	Every 15 minutes
0 0 1 * *	First day of every month at midnight
0 */2 * * *	Every 2 hours
30 8 * * 1	Every Monday at 8:30 AM

QuickFlo displays a human-readable summary of the cron expression below the input field (e.g., “At 06:00 AM, every day (UTC)”). Need help building expressions? The config links to crontab.guru.

Note

All cron schedules run in UTC. Factor in the timezone offset when scheduling for specific local times.

Passing Initial Data

The Initial Data field accepts a JSON object that becomes available in the workflow as {{ initial.* }}:

{
  "reportType": "daily",
  "emailTo": "admin@example.com"
}

{{ initial.reportType }}   // "daily"
{{ initial.emailTo }}      // "admin@example.com"

This is useful for parameterizing a single workflow that runs on multiple schedules with different configurations — for example, one schedule for a daily report and another for a weekly summary, both using the same workflow with different reportType values.

---

Form Triggers

Form triggers let you create hosted forms with a drag-and-drop builder that trigger a workflow on submission. Forms support custom branding, field validation, password protection, file uploads, CSV bulk submission, and fully customizable response screens.

See the Form Triggers guide for the complete walkthrough.

---

Event Triggers

Event triggers listen for real-time events from connected services. When a matching event occurs, the workflow starts automatically with the event payload as input data.

Event triggers are configured by selecting a connection and an event type. The available events depend on the connected service — for example, a Five9 connection can listen for agent state changes, call events, or queue updates.

Accessing Event Data

Event payloads are spread directly onto {{ initial.* }}:

{{ initial.eventType }}
{{ initial.data.agentId }}
{{ initial.data.newState }}

The structure of the event data depends on the source service. Check the event payload in the Executions panel after a test event to see the exact field structure.

---

Multiple Triggers

A single workflow can have multiple triggers of different types. For example, you might have:

• A webhook trigger for on-demand API calls
• A schedule trigger for nightly batch processing
• A form trigger for manual submissions from an internal team

All triggers feed into the same workflow — the trigger type and data are available via {{ initial.* }}. Use the Executions page to see which trigger started each execution.

Note

A workflow can have many triggers, but each trigger belongs to exactly one workflow. This one-to-one relationship between a trigger and its workflow keeps your system simple to reason about — you always know exactly which workflow a trigger will run.