Testing and Verifying a Trigger End-to-End

Before you turn a workflow on, confirm that its trigger actually fires and produces the data your downstream nodes expect by sending a real test event and reading the resulting execution.

Overview

A trigger is the entry point of every Spojit workflow. It decides when a run starts and what data the first step receives. The five trigger types behave differently: a Manual trigger waits for you to press a button, a Webhook trigger waits for an HTTP POST, a Schedule trigger fires on a cron expression, an Email trigger polls a connected mailbox, and a Mailhook trigger fires the moment mail lands at a generated address. Because each one is wired to a different external event, you cannot assume a trigger works until you have made that event happen for real and watched a run appear.

Verifying a trigger means two things: confirming it fires at all, and confirming the trigger output matches what your Transform, Condition, and Connector nodes reference with {{ input }}. The most reliable way to do both is to send a controlled test event, open the execution it creates in the run history, and inspect the trigger step's output. This guide walks through how to do that for every trigger type, so you catch a missing field or a misrouted address while you are still building, not after a real event slips through.

Before You Start

Open the workflow in the Workflow Designer and click the trigger node so you can see its configuration in the properties panel.
For an Email trigger, make sure the Gmail or Outlook trigger connection is already added under Connections and the folder and poll interval are set.
For a Mailhook trigger, make sure you have generated the email address and copied it.
You do not need to enable the workflow to test a Manual run, but Webhook, Schedule, Email, and Mailhook triggers only fire when the workflow is enabled.

Steps

Testing a Manual trigger

A Manual trigger is the easiest to verify because you control the event directly. In the Workflow Designer, click the Run button on the canvas toolbar. If your Manual trigger expects a request body, supply it in the run dialog so downstream steps that read {{ input }} have data to work with. Spojit starts an execution immediately and the trigger output equals the request body you passed. Open the run in the execution history and confirm the first step shows the exact body you sent.

Testing a Webhook trigger

A Webhook trigger fires when an external system sends an HTTP POST to the workflow's URL. To test it, enable the workflow, then send a test POST to that URL from the tool the source system uses, or from any HTTP client, with a JSON body that mirrors a real payload. If the trigger uses a signing connection (Spojit, Shopify, GitHub, Slack, or Custom), your test request must include a valid signature header, otherwise the request is rejected before a run starts. A successful call returns 202 with an executionId in the response. The trigger output is the parsed JSON body, available as {{ input }} (or { raw: "..." } when the body is not JSON). Use the returned executionId to open the exact run and check the body parsed the way you expect.

Testing a Schedule trigger

A Schedule trigger fires on a 5-field Unix cron expression in a chosen IANA timezone, for example 0 9 * * 1-5 in Australia/Sydney. You cannot press a button to make a schedule fire, so to verify it without waiting for the real time, temporarily set the cron to a moment a minute or two ahead (for example, the next minute), save, make sure the workflow is enabled, and wait for the run to appear in the execution history. The trigger output is { scheduledAt }, a timestamp marking when the schedule fired. Once you have confirmed a run was created at the expected time, restore the cron to its real value and save again. Remember a single trigger can hold multiple schedules, so test each one you have added.

Testing an Email trigger

An Email trigger polls a connected Gmail or Outlook mailbox on an interval of 1 to 60 minutes (default 2). To test it, send a real email into the watched folder of the connected mailbox from an address and with a subject that satisfy any From allowlist or Subject regex filter you configured. Then wait for the next poll. A run appears once the new message is picked up, so allow up to your poll interval before deciding it did not fire. The trigger output includes from, to, cc, subject, textBody, htmlBody, headers, receivedAt, conversationId, and attachments[]. Open the resulting execution and confirm the fields your workflow reads, such as {{ input.subject }} and {{ input.textBody }}, are populated.

Testing a Mailhook trigger

A Mailhook trigger fires within seconds of any mail arriving at the unique address Spojit generated for it (for example mh-ab12cd34ef56gh78@mailhook.spojit.com). To test it, send an email to that exact address from an account that passes any From allowlist or Subject regex filter you set. Because the Mailhook trigger fires whether the address is in To, Cc, or Bcc, sending directly to it is the simplest test. A run starts almost immediately. The trigger output is available as {{ input }} and includes from, to[], cc[], replyTo[], subject, text, html, truncated, receivedAt, and attachments[]. Open the execution and confirm those fields. If you reply to senders later in the workflow with a Send Email node, check that {{ input.replyTo }} resolved to the address you expect.

Reading the execution to verify the trigger output

For every trigger type, the proof is in the run. Open the workflow's execution history (or follow the executionId a Webhook call returned), select the run you just created, and click the trigger step. The step output shows exactly what the first node passed downstream. Compare that structure against every place your workflow references {{ input }}: if a field you expected is missing or named differently, fix the reference before you enable the workflow. If no run appeared at all, the trigger did not fire, and the cause is usually a disabled workflow, an unmet filter, a poll interval that has not elapsed, or a rejected signature.

Tips

When you are unsure why a run did not appear or why a field is empty, ask Miraxa, the intelligent layer across your automation. It knows the workflow you are editing and can investigate the trigger configuration and the last run for you.
Send a test event that mirrors the messiest real payload you expect, including extra fields and odd characters, so you verify the trigger output against realistic data rather than a clean sample.
For Schedule triggers, test in the same timezone you will run in. A cron that looks right in one timezone can fire an hour off after a daylight-saving change.
Mailhook deduplicates per message, so resending the identical test email may not start a second run. Change the subject slightly to force a fresh run.

Common Pitfalls

Forgetting to enable the workflow. Manual runs work from the Run button while editing, but Webhook, Schedule, Email, and Mailhook triggers only fire when the workflow is enabled.
Sending a Webhook test without a valid signature when a signing connection is configured. The request is rejected before any run is created, so it looks like the trigger silently failed.
Expecting an Email trigger to fire instantly. It polls on an interval, so a run can take up to a minute or more to appear depending on your poll setting.
Reading {{ input }} fields that the trigger does not actually return. Each trigger type has its own output shape, so always confirm the real field names in the trigger step output before wiring downstream nodes.