Workflows
Events

Events

Events trigger workflow executions. The event that triggers your workflow depends on the trigger you select for your workflow:

  • HTTP triggers invoke your workflow on HTTP requests.
  • Cron triggers invoke your workflow on a time schedule (e.g., on an interval).
  • Email triggers invoke your workflow on inbound emails.
  • Event sources invoke your workflow on events from apps like Twitter, Google Calendar, and more.

Selecting a test event

When you test any step in your workflow, Pipedream passes the test event you select in the trigger step:

Selecting a test event in the trigger

You can select any event you've previously sent to your trigger as your test event, or send a new one.

Examining event data

When you select an event, you'll see the incoming event data and the event context for that event:

The event and context in a trigger initiation

Pipedream parses your incoming data and exposes it in the variable steps.trigger.event, which you can access in any workflow step.

Copying references to event data

When you're examining event data, you'll commonly want to copy the name of the variable that points to the data you need to reference in another step.

Hover over the property whose data you want to reference, and click the Copy Path button to its right:

Copy an event path

Copying the values of event data

You can also copy the value of specific properties of your event data. Hover over the property whose data you want to copy, and click the Copy Value button to its right:

Copy event attribute value

Event format

When you send an event to your workflow, Pipedream takes the trigger data — for example, the HTTP payload, headers, etc. — and adds our own Pipedream metadata to it.

This data is exposed in the steps.trigger.event variable. You can reference this variable in any step of your workflow.

You can reference your event data in any code or action step. See those docs or the general docs on passing data between steps for more information.

The specific shape of steps.trigger.event depends on the trigger type:

HTTP

PropertyDescription
bodyA string or object representation of the HTTP payload
client_ipIP address of the client that made the request
headersHTTP headers, represented as an object
methodHTTP method
pathHTTP request path
queryQuery string
urlRequest host + path

Cron Scheduler

PropertyDescription
interval_secondsThe number of seconds between scheduled executions
cronWhen you've configured a custom cron schedule, the cron string
timestampThe epoch timestamp when the workflow ran
timezone_configuredAn object with formatted datetime data for the given execution, tied to the schedule's timezone
timezone_utcAn object with formatted datetime data for the given execution, tied to the UTC timezone

Email

We use Amazon SES to receive emails for the email trigger. You can find the shape of the event in the SES docs.

steps.trigger.context

steps.trigger.event contain your event's data. steps.trigger.context contains metadata about the workflow and the execution tied to this event.

You can use the data in steps.trigger.context to uniquely identify the Pipedream event ID, the timestamp at which the event invoked the workflow, and more:

PropertyDescription
deployment_idA globally-unique string representing the current version of the workflow
emitter_idThe ID of the workflow trigger that emitted this event, e.g. the event source ID.
idA unique, Pipedream-provided identifier for the event that triggered this workflow
owner_idThe Pipedream-assigned workspace ID that owns the workflow
platform_versionThe version of the Pipedream execution environment this event ran on
replayA boolean, whether the event was replayed via the UI
trace_idHolds the same value for all executions tied to an original event. See below for more details.
tsThe ISO 8601 timestamp at which the event invoked the workflow
workflow_idThe workflow ID
workflow_nameThe workflow name

How do I retrieve the execution ID for a workflow?

Pipedream exposes two identifies for workflow executions: one for the execution, and one for the "trace".

steps.trigger.context.id should be unique for every execution of a workflow.

steps.trigger.context.trace_id will hold the same value for all executions tied to the same original event, e.g. if you have auto-retry enabled and it retries a workflow three times, the id will change, but the trace_id will remain the same. For example, if you call $.flow.suspend() on a workflow, we run a new execution after the suspend, so you'd see two total executions: id will be unique before and after the suspend, but trace_id will be the same.

You may notice other properties in context. These are used internally by Pipedream, and are subject to change.

Event retention

On the Free and Basic plans, each workflow retains at most 100 events or 7 days of history.

  • After 100 events have been processed, Pipedream will delete the oldest event data as new events arrive, keeping only the last 100 events.
  • Or if an event is older than 7 days, Pipedream will delete the event data.

Other paid plans have longer retention. See the pricing page for details.

Events are also stored in event history for up to 30 days, depending on your plan. See the pricing page for the retention on your plan.

Events that are delayed or suspended are retained for the duration of the delay. After the delay, the workflow is executed, and the event data is retained according to the rules above.

ℹ️

For an extended history of events across all of your workflows, included processed events, with the ability to filter by status and time range, please see the Event History.