Events
Trigger Event
Trigger an event for a subscriber
POST
Trigger Event
Trigger an event for a subscriber. Creates the subscriber and/or event definition if they don’t exist. Events can trigger automations and apply sync rules.
For a live event, if this contact already has an event with that ID and that name, nothing is
recorded, no sequences enroll, no sync rules apply, no webhooks fire, and the
response returns the existing event with
The ID is scoped to the contact and the event name, so keying
An Using
If this event starts a sequence with
Request Body
string
Subscriber delivery email address. Required when creating a new subscriber.
string
Your app/customer/user ID for this subscriber. You can trigger events with
only
externalId when the subscriber already exists.string
required
Event name (e.g.,
purchase_completed, saas.purchase)object
Event properties/metadata. Can contain any key-value data.
string
First name for the subscriber created or updated by this request. Omit to
leave an existing value unchanged.
string
Last name for the subscriber created or updated by this request. Omit to leave
an existing value unchanged.
object
Custom attributes to set on the subscriber.
string
ISO 8601 timestamp of when the event actually happened. Defaults to now. A
timestamp more than an hour in the past records the event as history - see
Recording events that already
happened.
string
Your own ID for this event, used as an idempotency key on both the live and
historical paths. Live retries return
duplicate: true; historical retries
increment duplicates. See Retrying the same
event.Retrying the Same Event
Producers retry. A queue redelivers, an automation tool re-runs a node, a request times out after it was already handled. Pass your owneventId and
Sequenzy treats a repeat as the same occurrence:
duplicate: true:
saas.purchase
and saas.refund off the same order ID records both. Without an eventId a
repeat is recorded as a second occurrence - we cannot tell a retry from a
customer who genuinely bought twice.
Auto-Creation Behavior
This endpoint automatically creates resources if they don’t exist:
New subscribers created by this endpoint follow your workspace default lists
setting.
What Happens When an Event is Triggered
- Event Recorded - Stored in analytics for reporting
- Sync Rules Applied - Tags automatically added/removed based on rules
- Automations Triggered - Sequences with matching event triggers start
Recording Events That Already Happened
When you migrate from another platform, or backfill history from your own database, you want the events to carry the dates they really happened on. Otherwise every imported purchase looks like it happened today and segments like “purchased in the last 90 days” are wrong. PassoccurredAt to say when the event happened:
occurredAt more than an hour in the past is treated as history, and
the behavior changes deliberately:
Timestamps within the last hour stay on the live path, so queue lag, retries and
clock skew behave exactly as before.
You can set your flows up first. Importing history is safe whatever order
you do it in - build and switch on every sequence you want, then bring your
data over. Historical events are also kept out of the calculations that
time-based flows use to pick people, so importing a year of purchases will not
satisfy a “bought 5 times in the last 30 days” flow, and importing contacts
will not make a “joined recently” flow treat them as new arrivals. They still
count for the segments and reports themselves - only the enrollment decision
ignores them.
Signup dates. An event at time T proves the contact existed at T, so a
historical event also moves the contact’s signup date back to the earliest
event you import - never later. A contact created by the import gets that date
instead of today’s, so date-added segments and growth reports do not read a
migration as a wave of new signups.
Idempotency. Pass
eventId and a re-run writes nothing new, exactly as on
the live path, but the historical response reports skipped rows through its
duplicates count rather than the live path’s duplicate flag and singular
event (see Retrying the same event). Imports go
further: without an eventId Sequenzy derives a stable ID from the contact,
event name, timestamp and properties, so an identical historical event sent
twice still produces one row. Live events get no such fallback, because two
identical purchases seconds apart are a real thing customers do.
Retention. Events are kept for 5 years. A timestamp older than that is
rejected with a 400 rather than accepted and silently dropped. To represent a
contact who joined longer ago than that, set their signup date with
createdAt on Create Subscriber instead -
subscriber records have no such limit.
Using properties in Sequence Emails
If this event starts a sequence with trigger: "event_received", Sequenzy stores the properties object on that sequence run and makes it available in later emails through event. merge tags.
Examples:
{{event.amount}}{{event.product}}{{event.order.id}}{{event.city|your area}}
Built-in Events
These events have special behavior with default sync rules:Double Opt-In
When the workspace has double opt-in enabled and the event creates a brand-new subscriber, the subscriber is stored pending confirmation, the confirmation email is queued, and sequences triggered by the event wait at their trigger step until the subscriber confirms. The response then includes anoptIn object.
Responses
Response Fields
Use Cases
E-commerce Purchase
Feature Activation
Subscription Lifecycle
Events can trigger automation sequences. If you have a sequence set to start
when this event is received, it will begin automatically for the subscriber.