# Track data ## OpenAPI Specification ```yaml openapi: 3.0.1 info: title: '' description: '' version: 1.0.0 paths: /{orgName}/projects/{projectName}/sources/{sourceId}/track: post: summary: Track data deprecated: false description: "Ingest tracking events into Intempt via HTTP.\nThis endpoint accepts one or more tracking events in a single request and sends them directly into Intempt’s real-time ingestion pipeline for processing, identity resolution, and analytics.\nUse this endpoint when:\n\t•\tTracking events from backend or server-side systems\n\t•\tSending events from environments where the Intempt SDK is not available\n\t•\tSyncing behavioral, transactional, or lifecycle data from custom backends or integrations" operationId: track-data tags: [] parameters: - name: orgName in: path description: Organization name required: true example: '' schema: type: string default: demo-organization - name: projectName in: path description: Name of a project required: true example: '' schema: type: string default: demo-project - name: sourceId in: path description: >- Source identifier representing where the event data originates (web, backend, integration). required: true example: 0 schema: type: integer format: int64 default: 1001 - name: apiKey in: query description: >- API key used to authenticate the request and identify the source sending data. required: true schema: type: string default: identifier.secret requestBody: content: application/json: schema: type: object required: - track properties: track: type: array items: properties: name: type: string description: >- Logical name of the event being tracked (for example: Purchase, Signup, Subscription Updated). payload: type: array items: properties: eventId: type: string description: >- Optional auto generated event identifier. In most cases, the event identifier is a randomly generated UUID. Events with the same name and an existing event ID will not be processed. This field is mandatory. For session or page events, the event ID should match the sessionId or pageId, depending on the context. userId: type: string description: >- User unique identifier. This optional field allows you to identify a user using a unique email, phone number, or external ID. Required when the profileId is null. timestamp: type: integer description: >- Event timestamp in milliseconds. If not set, the current timestamp will be applied. format: int64 accountId: type: string description: >- Account unique identifier. The optional field allows you to identify account, group of users using a unique company name, domain, or external ID. sessionId: type: string description: >- Unique session identifier. A temporal identifier that groups multiple events within a single session. For session events such as start or end, the identifier value should match the event ID, ensuring consistency and continuity within the session. pageId: type: string description: >- Unique page identifier. A temporal identifier that groups multiple events within a page. For page events such as view or leave, the identifier value should match the event ID, ensuring consistency and continuity within the page. anotherUserId: type: string description: >- User identifier for merging. Used for merging users with different types of identifiers. When the userId field is an email identifier, anotherUserId can be a phone identifier. The combination of these fields merges the user with userId and the user with anotherUserId into a single entity, creating a unified profile. anotherAccountId: type: string description: >- Account identifier for merging. Used for merging accounts with different types of identifiers. When the accountId field is a company name identifier, anotherAccountId can be a company email identifier. The combination of these fields merges the account with accountId and all users inside into the account with anotherAccountId into a single entity, creating a unified profile. data: type: string description: >- This JSON field holds custom event attributes with no restrictions on the types of data you can include. These attributes can range from details such as purchaseAmount to geographical data such as locationLatitude, among many other possibilities. Feel free to use this field to provide additional context and insights for each event. format: json userAttributes: type: string description: >- The JSON field holds custom user attributes with no restrictions on the types of data you can include. format: json accountAttributes: type: string description: >- The JSON field holds custom account attributes with no restrictions on the types of data you can include. format: json type: object x-apidog-orders: - eventId - userId - timestamp - accountId - sessionId - pageId - anotherUserId - anotherAccountId - data - userAttributes - accountAttributes description: >- Array of event objects. Each object represents a single occurrence of the event. required: - name type: object x-apidog-orders: - name - payload description: >- List of tracking groups. Each group defines an event name and one or more event payloads associated with that name. x-apidog-orders: - track examples: '1': value: track: - name: Purchase payload: - eventId: generated-event-id userId: custom@intempt.com timestamp: 1714631904000 accountId: Intempt sessionId: generated-session-id pageId: generated-page-id anotherUserId: '+111111111' anotherAccountId: no-reply@intempt.com data: amount: 150 productName: Wine quantity: 4 locationLatitude: 51.509865 userAttributes: location: USA accountAttributes: founded: 2000 summary: Single Event - Purchase (full payload + identity fields) description: "Use this example when you want to send one event occurrence into Intempt.\n\nThis shows the complete shape of a Track API payload:\n\t•\ta single track[] group with one name\n\t•\ta single payload[] event object\n\t•\tcore identifiers like eventId, profileId, userId, timestamp\n\t•\toptional identity linking fields like anotherUserId, anotherAccountId\n\t•\tevent metadata inside data\n\t•\tprofile/account enrichment via userAttributes and accountAttributes\n\nBest for: backend purchase tracking, CRM sync triggers, or “important business moments”." '2': value: track: - name: Purchase payload: - eventId: evt_purchase_001 profileId: profile_user_1 userId: user1@example.com timestamp: 1714631904000 sessionId: sess_001 pageId: checkout_page data: amount: 200 productName: Whiskey quantity: 2 - eventId: evt_purchase_002 profileId: profile_user_2 userId: user2@example.com timestamp: 1714631910000 sessionId: sess_002 pageId: checkout_page data: amount: 90 productName: Beer quantity: 6 summary: Batch Events — Multiple Purchases in One Request description: "Use this example when your backend needs to send multiple events of the same type in one call.\n\nWhy this matters:\n\t•\treduces network overhead (one request instead of many)\n\t•\tideal for high-volume systems (orders, payments, imports)\n\t•\teach object inside payload[] is treated as a separate event with its own IDs and data\n\nBest for: batch order processing, webhook fan-out pipelines, nightly exports." '3': value: track: - name: Signup payload: - eventId: evt_signup_001 profileId: profile_new_user userId: newuser@example.com timestamp: 1714631800000 data: signupMethod: email userAttributes: plan: trial country: IN - name: Purchase payload: - eventId: evt_purchase_003 profileId: profile_new_user userId: newuser@example.com timestamp: 1714631904000 data: amount: 120 productName: Vodka quantity: 1 summary: Multiple Event Types — Signup + Purchase in One Request description: "Use this example when your system produces multiple event types in the same execution flow.\n\nKey idea:\n\t•\tthe track[] array can contain multiple groups\n\t•\teach group has its own name and payload\n\t•\tthis keeps event types clean while still allowing one request\n\nBest for: signup flows, onboarding pipelines, “user action → follow-up action” flows." responses: '200': description: '200' content: application/json: schema: type: object properties: {} x-apidog-orders: [] examples: '1': summary: Successful ingestion — Purchase event accepted value: {} '2': summary: Successful ingestion — Batch events accepted value: {} '3': summary: Partial validation handled internally (still 200 OK) value: {} headers: {} x-apidog-name: OK '400': description: '400' content: application/json: schema: type: object properties: {} x-apidog-orders: [] headers: {} x-apidog-name: Bad Request security: [] x-apidog-folder: '' x-apidog-status: released x-run-in-apidog: https://app.apidog.com/web/project/1137771/apis/api-24815715-run components: schemas: {} securitySchemes: {} servers: [] security: [] ```