Connecting TikTok to Your Tracker: Click ID, Postback and S2S
There are two TikTok APIs and conflating them costs people months. The Marketing API, which creates campaigns, needs an approved developer application. The Events API, which reports conversions back, does not — its token is generated inside Events Manager. If you have been told server-side tracking is out of reach, that is why it is not.
The loop, end to end
Four moving parts. Each one is simple; the trouble is always in the joins.
- TikTok appends a click ID to your destination URL when someone clicks
- Your tracker stores it against the click
- When a conversion happens, the tracker fires a postback carrying that click ID
- Something forwards the conversion to TikTok through the Events API, so optimisation can see it
Skip the last step and you have reporting but no optimisation signal. TikTok will keep buying blind.
Step 1: get the click ID into your URL
TikTok passes its click identifier as ttclid on the landing page URL. In the ad’s destination field you add a parameter your tracker will read, and you also want your own campaign-level identifiers so reports are readable later.
A workable shape, with names matching whatever your tracker expects:
https://yourtracker.com/click?campaign_id=__CAMPAIGN_ID__&adgroup_id=__AID__&ad_id=__CID__&ttclid=__CLICKID__
TikTok substitutes the macros at click time. Build this once per campaign and keep it in the bulk file so every ad carries it identically — hand-entering tracking parameters per ad is where they diverge.
Step 2: store it, and store it long enough
The tracker keeps the click ID against the click. Two settings matter and both get left at defaults by people who later cannot explain a gap.
Click storage window. If your tracker discards clicks after seven days and conversions arrive on day nine, those conversions have no click to attach to. For anything with a delayed payable event, raise it.
What you pass through on the postback. The click ID has to survive into the conversion notification. If the advertiser’s postback only returns an internal order ID, there is nothing to map back.
Step 3: the Events API token — the part people get wrong
This is the step usually described as requiring API access. It does not. TikTok generates an Events API token from the pixel itself, and recommends that route over a developer application.
- Ads Manager › Assets › Events
- Open the pixel, then Settings
- Find the Events API section and generate the access token
The token is shown once. Refresh the page and it is gone, and you generate a new one. Put it straight into a secrets store or an environment variable — never into client-side code, never into a repository.
One permission caveat that ties back to whose account you are on: generating this token needs admin or standard access with event management permissions. Campaign-level access is not enough. On a rented account you may have to ask the provider, and they may decline — the same structural problem as connecting third-party tools, with a lower barrier.
Step 4: send the event
Server events go to the Events API v1.3 track endpoint. The request carries the token in an Access-Token header and identifies the destination with your pixel code as the event source. Each event carries the click ID you stored, so TikTok can attribute it to the click that produced it.
With a token generated in Events Manager, the documented rate limit is 1,000 requests per second per advertiser account — far above anything a single buyer will produce, so throughput is not a design concern.
The deduplication trap
The Events API runs alongside the pixel, it does not replace it. That means the same conversion can be reported twice — once by the browser, once by your server — and TikTok does not deduplicate server-side events automatically.
Two valid approaches, and mixing them is the mistake:
- Pick one source per event. Fire a given event either from the browser or from the server, never both.
- Send both with a shared event ID. Generate one identifier per conversion and include it in both the browser and server event, so they can be collapsed into one.
What produces inflated numbers is sending both with no shared identifier. What produces missing numbers is assuming the server send replaced the pixel and removing the pixel.
Verifying it before you spend
Events Manager has Test Events and Diagnostics tabs. Use them — server-side events do not appear in the browser pixel helper, so the browser tools will tell you nothing.
Expect lag. An event can take time to surface in Events Manager, and an optimisation event does not become selectable in campaign setup until it has actually fired. Waiting a day before concluding something is broken saves a lot of pointless rebuilding.
Pixel first, confirm events arrive. Then the tracker, confirm click IDs are stored. Then the server send, confirm in Test Events. Then turn off whichever duplicate source you decided against. Changing two layers at once makes the failure unattributable.
The short version
- Marketing API needs approval; Events API does not — the token comes from Events Manager
- Generating it needs event management permissions, not just campaign access
- The token is shown once; copy it immediately
- Pass the click ID in the destination URL and keep the click storage window long enough
- Events API runs alongside the pixel — one source per event, or a shared event ID
- Verify in Test Events, and allow for reporting lag before debugging