Skip to main content
Product events are the actions your product users take in your product, like viewing a page or starting a trial. Send them with POST /v2/product-events (one event) or POST /v2/product-events/batch (up to 5,000 events). Both need a token with WRITE access.
eventId, userId, eventName, timestamp, and properties are required. orgId is optional.

​
Accepted is not stored

A 202 means the event passed validation and is durably queued. It does not mean the event is stored yet. Each event name starts disabled. Its events are archived but not stored or used by triggers until you enable the event name in Product Data Explorer. The name appears there after its first event. Enabling takes effect within minutes and back-fills that event’s recent history from the archive. Back-filled events do not fire triggers.
Send one test event first, then enable its event name in Product Data Explorer before you start a large backfill.

​
Identity

userId is the product user ID used by POST /v2/users. orgId is the organization ID. Events never create or update product users or organizations. Events for an ID that doesn’t exist yet are kept and link up once it exists.

​
Timestamps

timestamp accepts any of these:
Send milliseconds, not seconds. A Unix timestamp in seconds resolves to a date in 1970.
A date alone, a space instead of T, a numeric string, and offsets like +0530 are rejected.

​
Properties

properties is an object with 1 to 256 top-level keys. Nested objects and arrays are stored, but only top-level string, number, and boolean values can be used in dynamic lists and triggers.

​
Deduplication and retries

eventId identifies an event within your workspace. A repeat within the deduplication window is rejected with DUPLICATE_EVENT. Always retry with the same eventId:
  • Resend events rejected with DEPENDENCY_UNAVAILABLE.
  • Resend the whole request after a 500.
  • On a retry, DUPLICATE_EVENT normally means the event was already accepted.
In one batch, valid events that share an eventId are all rejected.

​
Responses

Product event responses contain only errors and meta. Accepted events are not listed individually. meta.correlationId identifies the request; include it when you contact support.
A batch returns 202 with SUCCESS when every event is accepted, or PARTIAL_SUCCESS when some are rejected. Error paths keep each event’s original index (/events/1/...), so you can match errors back to your input.

​
Limits

See Rate limits for how this budget relates to the rest of the API.