Testing — Listen for Trigger
Purpose
Test trigger-based workflows safely before enabling them in production. Each trigger type provides a dedicated test-listen mode that captures a real event and runs the downstream workflow so you can inspect every node's output in one pass.
Workflow does not need to be enabled. All test-listen modes work on both enabled and disabled workflows.
HTTP Trigger — Listen for Request
Use this when your workflow starts with http_trigger.
Flow
Steps
- Select the
http_triggernode and open the config panel (or use the toolbar button). - Click Listen for Request.
- Copy the generated test URL.
- Send an HTTP request to that URL (curl, Postman, or any HTTP client).
- The builder captures the request payload and runs the downstream workflow.
- Inspect each node's output panel.
Validation checks
- Path, query, header, and body fields captured correctly.
- Conditional branches execute expected path.
- Response node returns expected status and payload.
Common issues
- Test URL expired before request was sent — restart the session.
- Request method does not match trigger configuration.
- Expression references wrong node identifier.
- Session already has an active listener — stop and restart.
IMAP Trigger — Listen for Email
Use this when your workflow starts with imap_trigger.
Flow
Steps
- Select the
imap_triggernode and ensurecredentials_idandmailboxare configured. - Click Listen for Email in the config panel or toolbar.
- Send a test email to the configured IMAP account (or ensure an unseen email already exists).
- The builder captures the first unseen email and runs the downstream workflow.
- Inspect each node's output panel.
At-most-once: listen-for-email is read-only and does not mark messages as
\Seen, so the same email can be captured again in subsequent test sessions.
What is captured
| Field | Description |
|---|---|
subject | Email subject line |
from | Sender address |
to | First recipient address |
date | Date header (RFC3339) |
body_text | Plain-text body |
body_html | HTML body (empty string if absent) |
uid | IMAP UID of the message |
mailbox | Mailbox folder |
Common issues
- No unseen email found — the session returns a timeout after ~2 minutes; send a test email and retry.
- Wrong credentials ID — validate the credential first in Settings → Credentials → Validate Connection.
- Wrong mailbox name — use the exact folder name the server exposes (case-sensitive on some servers).
- Firewall blocking outbound IMAP (port 993) from the backend host.
Cron, Kafka, and Manual Triggers — Execute Workflow
For these trigger types, there is no external event to capture. Use Execute Workflow in the toolbar, which injects mock trigger data and runs the full graph:
| Trigger | Mock data injected |
|---|---|
cron_trigger | triggered_at (current time), trigger, schedule, timezone, run_id |
kafka_consumer | topic, partition, offset, key, message, headers, run_id |
manual_trigger | triggered_at (current time), trigger |
Session and stream caveats
- Listen sessions are short-lived (≈10 minutes max) and intended for test windows, not persistent ingestion.
- If the UI stream stops updating, create a fresh session and resend or resend the email.
- One active listener per workflow at a time — starting a new session cancels the previous one.
Security notes
- Generated listen URLs are temporary test endpoints, not production webhooks — treat them accordingly.
- Share listen URLs only with the tester during the active session window.
- Keep test payloads sanitized; do not use production secrets or PII in listen-mode tests.