Skip to main content
POST
Ingest an event

Endpoint

POST /events

Request body

You can also identify a contact with external_id or email. Use correlation when an identity can have more than one active business flow. For checkout recovery, send the same checkout_id with both checkout.started and checkout.completed; a correlated wait resumes only its matching checkout. To create or merge an email contact while ingesting an event, opt in explicitly:
Without contact.mode: "upsert", event ingestion resolves existing contacts only. Identity resolution order is:
  1. contact_id
  2. external_id
  3. normalized email

Successful response

New customer events currently return 202 Accepted.

Idempotent replay response

If you reuse the same idempotency_key, Sendrealm returns the existing event instead of creating a new one:

Reserved namespace

Customer-submitted events must not start with sendrealm.. Examples of Sendrealm system events:
  • sendrealm.mail.delivery
  • sendrealm.push.open
  • sendrealm.contact.updated
  • sendrealm.topic.subscribed

Guarantees and limits

  • Event ingest is at-least-once.
  • Idempotency is enforced by project_id + idempotency_key.
  • Payload size is capped by the project’s configured event payload limit.
  • Processing retries use exponential backoff before a dead-letter handoff.
  • Ordering across separate events is not guaranteed.

Retention

  • Default event retention is 90 days.
  • Retention windows can be adjusted through backoffice-managed project automation settings.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Body

application/json
event
string
required
Example:

"order.completed"

contact_id
string<uuid>
email
string<email>
external_id
string
payload
object
correlation
object
contact
object
occurred_at
string<date-time>
idempotency_key
string

Response

Event replay deduplicated

data
object