Skip to main content
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.

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.
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. Re-sending the same eventId for a historical event writes nothing new, so an interrupted import is safe to re-run.

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

  1. Event Recorded - Stored in analytics for reporting
  2. Sync Rules Applied - Tags automatically added/removed based on rules
  3. 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. Pass occurredAt to say when the event happened:
An occurredAt more than an hour in the past is treated as history, and the behavior changes deliberately:
Historical events never run automations. This is what makes it safe to import years of history in one afternoon: without it, every imported purchase would enroll the contact in your purchase sequence and send a real email. Do not use occurredAt to test a live automation - the side effects you are testing will not run.
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. Without one, Sequenzy derives a stable ID from the contact, event name, timestamp and properties, so an identical event sent twice still produces one row. 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}}
That means the second or third email in the same sequence can still use the original event payload without copying those values onto the subscriber profile.

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 an optIn 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.