Skip to main content
POST
Trigger Events (Bulk)
Trigger multiple events for a subscriber in one request. Creates the subscriber and/or event definitions if they don’t exist.
Events are processed independently. If one event fails, previously triggered events are not rolled back, so retry an error response as a partial success.

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.
array
required
Array of events to trigger. At most 500 per request.
string
required
Event name
object
Event properties/metadata
string
ISO 8601 timestamp of when this event actually happened. Defaults to now. See Importing history.
string
Your own ID for this event, making a re-run idempotent.
object
Custom attributes to set on the subscriber.

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.

Double Opt-In

When the workspace has double opt-in enabled and this request creates a brand-new subscriber, the subscriber is stored pending confirmation and a single confirmation email is queued for the whole request. All events are still recorded, and sequences triggered by them wait at their trigger step until the subscriber confirms. The response then includes an optIn object.

Responses

Response Fields

Use Cases

Track User Session

Record Funnel Progress

Each event in the bulk request is processed independently. Sync rules and automation triggers are evaluated for each event, and successful events are not rolled back if another event in the same request fails.

Importing History

Give each event an occurredAt and it is stored with the date it really happened, so date-relative segments are correct straight after a migration instead of treating your whole history as having happened today.
When every event in the batch is more than an hour old, the batch takes the historical path: one idempotent write, no sequences, no sync rules, no waiting steps, no goal conversions, no webhooks. The response carries historical: true along with inserted and duplicates counts.
Historical events do not run automations. That is what makes a large import safe - otherwise every imported purchase would enroll the contact and send a real email. A batch that mixes recent and old events stays on the live path, with each event keeping its own timestamp.
Re-running the same import writes nothing new: eventId makes each event idempotent, and events without one are deduplicated by their content. Events older than the 5-year retention window are rejected with a 400 rather than accepted and silently dropped.