Skip to main content
POST
Import Events (Many Subscribers)
Record a bounded batch of up to 25 events for many subscribers in one request - the pipeline companion to Trigger Event and Trigger Events (Bulk), built for data pipelines and warehouse syncs. Each event carries its own subscriber identity. Events are grouped per contact:
  • A contact whose events are all more than an hour old is imported as history in one idempotent write: stored with real timestamps, visible to segments and the timeline, but no sequences, sync rules, waiting steps, goals, webhooks, or double-opt-in confirmation emails run.
  • A contact with any recent event takes the live path with normal side effects, processed in order.
Contacts process independently, so an error response may still include recorded events. Treat errors as partial success and retry the same request - with an eventId on every event, a retry records nothing twice.

Request Body

object[]
required
One to 25 events. Every event requires a name, a source-owned eventId, and an email or an externalId. Email is required when creating a contact; an external-ID-only row must resolve to an existing contact. null identifier and timestamp values are treated as absent, so warehouse exports with null columns import cleanly. Keys outside the documented fields are ignored - keep row data inside properties, or it is silently discarded.
string
Subscriber delivery email address. Required when the event may create a new contact.
string
Your app/customer/user ID for this subscriber. It can be used without email only when it resolves to an existing contact.
string
required
Event name (e.g., purchase_completed, saas.purchase)
object
Event properties/metadata.
string
ISO 8601 timestamp of when the event actually happened. Defaults to now. Classification is per contact: only when all rows for that contact are more than an hour old is the group historical. Any recent row makes every event for that contact live while preserving each supplied timestamp.
string
required
Your source-owned ID for this event, used as an idempotency key on both the live and historical paths. Derive it from your source data (an order ID, a warehouse row key) so re-running the import is safe.

Responses

Counts

total = recorded + duplicates + failed. duplicates counts events whose eventId was already recorded for that contact and event name, so no second receipt was written. Live duplicate retries may idempotently re-attempt downstream recovery. sideEffectFailed is orthogonal to receipt accounting: it can accompany either a newly recorded row or a duplicate row whose downstream work (or historical automation shielding) still failed. subscribers is the number of distinct identities in the request.

Throughput

At 25 events per request within the standard rate limits, this endpoint sustains up to 2,500 events per minute while keeping each synchronous request bounded - use it instead of looping over the single-subscriber endpoints when syncing events from a pipeline or warehouse. See the data pipeline ingestion guide for the full recipe.