Ingest Events
Ingest API
Ingest Events
Send tracking events to Outlit
POST
Ingest Events
Endpoint
Path Parameters
Your organization’s public key. Starts with
pk_.Request Body
Body Parameters
Unique identifier for the visitor (UUID format). Required for browser (
client) tracking. For server-side tracking (server source), this can be omitted; identity or attribution is derived from email, userId, fingerprint, customerId, or billing identifiers in the events.Event source. One of:
client (browser), server, integration.Array of event objects to ingest (max 100 per request).
Optional user identity for immediate resolution. Used by browser SDK when user is logged in (via
setUser()). Allows direct identity resolution instead of anonymous visitor flow.| Property | Type | Description |
|---|---|---|
email | string | User’s email address |
userId | string | Your system-owned user/contact ID |
traits | object | User/contact traits |
Optional customer/account attribution for the whole batch. Used by browser SDK when the current user carries account/workspace context.
| Property | Type | Description |
|---|---|---|
customerId | string | Your system-owned customer/account/workspace ID |
customerTraits | object | Customer/account traits |
Event Types
All events share these common fields:| Field | Type | Required | Description |
|---|---|---|---|
type | string | Yes | Event type (see below) |
timestamp | number | No | Unix timestamp in milliseconds. Defaults to server time. |
url | string | Yes | Full page URL |
path | string | Yes | URL path (e.g., /pricing) |
referrer | string | No | Referrer URL |
utm | object | No | UTM parameters (see below) |
UTM Parameters
Pageview Event
Track a page view.Must be
"pageview".Page title.
Custom Event
Track any custom event.Must be
"custom".Name of the custom event.
Key-value pairs of event properties. Values can be string, number, boolean, or null.
Form Event
Track a form submission.Must be
"form".Identifier for the form (ID attribute or name).
Key-value pairs of form field values.
Identify Event
Identify the visitor with their email/userId.Must be
"identify".User’s email address. At least one of
email or userId required.Your system-owned user/contact ID.
Properties to set on the user profile.
Your system-owned customer/account/workspace ID. Send it with an identify event when you want that external account/workspace to link to the contact resolved from email or userId.
Properties to set on the customer profile.
Engagement Event
Track active time on a page. Automatically sent by the browser SDK.Must be
"engagement".Time in milliseconds the user was actively engaged (visible tab + user interactions).
Total wall-clock time in milliseconds on the page.
Session ID (UUID) for grouping engagement events. Resets after 30 min of inactivity or tab close.
Calendar Event
Track calendar booking from embedded widgets (Cal.com, Calendly).Must be
"calendar".Calendar provider:
"cal.com", "calendly", or "unknown".Meeting type name (e.g., “30 Minute Demo”).
Scheduled start time (ISO 8601 format).
Scheduled end time (ISO 8601 format).
Duration in minutes.
Whether this is a recurring meeting.
Invitee’s email (only available via server-side webhooks).
Invitee’s name (only available via server-side webhooks).
Stage Event
Track explicit activation milestones. Engaged and Inactive are derived automatically from tracked product activity, but the ingest API continues to accept those values for older SDKs and direct API callers.Must be
"stage".The journey stage. Use
"activated" for new integrations. "engaged" and "inactive" remain accepted for compatibility.Additional context for the stage transition.
The
discovered and signed_up stages are automatically inferred from identify events. Only use stage events for explicit activation milestone tracking.Billing Event
Track account billing status for custom billing systems. If Stripe is connected, billing status is handled automatically.Must be
"billing".The billing status. One of:
"trialing", "paid", "churned".Your system-owned customer/account/workspace ID. Public billing calls should use this identifier.
Stripe customer identifier. Prefer
customerId unless you are sending compatibility events that already use Stripe IDs.Additional billing context such as plan, amount, or cancellation reason.
Billing events require
customerId or stripeCustomerId. They target the account, not an individual contact.Response
Success Response
Whether the request was successful.
Number of events successfully processed.
Array of processing errors (only present if some events failed).
Partial Success Response (HTTP 207)
When some events succeed and others fail:Error Response
Examples
cURL - Browser Events
cURL - Server Events
JavaScript (fetch)
Python
Server-Side Events
For server-side tracking, thevisitorId field can be omitted. Identity is resolved from the event data, including customer-only attribution when customerId is provided:
- Identify events: Use
emailand/oruserIdfields, plus optional customer context - Custom events: Include top-level
email,userId,fingerprint, and/orcustomerIdfields - Billing events: Include
customerIdorstripeCustomerId
Batching Best Practices
For high-volume tracking:- Batch events - Send multiple events per request (up to 100)
- Use background queue - Don’t block user actions
- Retry with backoff - Handle temporary failures
- Flush on shutdown - Send remaining events before exit