TikTok Events API Migration: From Six Endpoints to One
The Name Untangled: 2.0 Is the Product, v1.3 Is the Version
The TikTok Events API migration conversation stumbles on naming before it reaches code - and on the phrase itself. "Events API 2.0" is TikTok's name for the unified endpoint - /event/track/ - that reports events from all sources: web, app, offline, and CRM. The v1.3 in documentation URLs and endpoint paths is a different axis entirely: the Marketing API version that the path carries. TikTok's own overview page lives at a URL containing both, and its curl example posts to https://business-api.tiktok.com/open_api/v1.3/event/track/ - a 2.0 endpoint whose path contains v1.3. Reading "2.0" and "v1.3" as competing versions is the fastest way to confuse a migration plan; one is the product generation, the other is the API version string.
For an affiliate funnel the distinction is practical: your integration targets the 2.0 endpoint (one route, unified payload), and the path prefix it lives under is just addressing that will move with future Marketing API versions.
What the Unified Endpoint Replaces
Events API 1.0 split delivery by source: one pair of endpoints for pixel events, another for offline, a third for app - each with its own payload dialect. TikTok's overview lists all six as sunset candidates for H2 2024: /pixel/track/ and /pixel/batch/, /offline/track/ and /offline/batch/, /app/track/ and /app/batch/. The recommendation is direct - new integrations should start on the unified endpoint, and existing 1.0 users should upgrade as soon as possible.
The unification matters beyond housekeeping. A tracker funnel that reports web conversions from a landing and offline-style status updates from a postback used to maintain two integrations with two schemas; on 2.0 both travel through the same events API route, differing only in the event_source field and their required objects. Less schema surface means fewer integration error classes to keep track of.
The 2.0 Payload Schema
The envelope is the structural change from 1.0: three fields sit above the events. event_source takes the enum web, app, offline, or crm; event_source_id carries the event source ID used for measurement (the pixel code for web); and data is the array of events - one object per event.
Inside each event: event names the conversion (standard or custom), event_time is the Unix timestamp, and event_id sets up deduplication against the pixel - the shared-key discipline covered in pixel and CAPI deduplication. The user object carries identifiers (TikTok's examples show hashed email and phone alongside raw IP and user agent - exact hashing rules live in the user parameters spec, and the general normalization logic is in CAPI user data hashing), while properties describes the product or order.
Source-specific objects are conditional but enforced: page is required for web events, app is required for app events, ad applies only to app, and lead is required for CRM events. The limited_data_use boolean exists for web and app sources only - the limited data processing flag in this schema.
Endpoint, Auth, and Limits
The URL is https://business-api.tiktok.com/open_api/v1.3/event/track/, and authentication uses an Access-Token header. TikTok recommends generating the access token directly in Events Manager rather than maintaining a developer app - the same credential source documented in the pixel ID and access token guide. A successful call returns HTTP 200 with an API response code of 0; failures come back as 4XX or 5XX with the error detail in the body.
Capacity is generous for a funnel: the endpoint accepts up to 1,000 events in a single request, with a rate limit of 1,000 QPS per advertiser account (or per developer app, when the token comes from one). TikTok still recommends sending single events as soon as the server receives them - batching is a recovery tool, not a default posture, because fresh events feed optimization best.
Migration Steps for an Existing Funnel
The mechanical path for an integration sending pixel events today: point the delivery at /event/track/, wrap the payload in the envelope with event_source: web and the pixel code in event_source_id, and move the fields into the user, properties, and page objects. An integration that also reported offline updates through /offline/track/ collapses onto the same route with event_source: offline - one sender, one schema. Pass the ttclid click ID and the _ttp cookie value exactly the way TikTok's click ID and cookie guides specify, since the pixel-side matching depends on them.
Then verify before switching traffic: send single test events, confirm the code: 0 response, and check Events Manager for the events arriving under the right pixel. If you would rather not own the migration at all, MOST delivers tracker postbacks to TikTok's Events API alongside Meta, Reddit, Pinterest, Snapchat, and OpenAI on the current schema, and the free Pixel Activator covers TikTok delivery for a single landing - or the Events API Gateway path if you operate many accounts.