Detecting conversion APIs: Meta CAPI, TikTok, LinkedIn, Enhanced Conversions

The check looks for traces of server-to-server conversion APIs in the HTML. It only sees what the browser gives away; a server container leaves none.

What we check

In the HTML: the scan looks for signatures of four server-to-server interfaces. Meta Conversions API by the events endpoint or an external_id in the pixel init, TikTok Events API by business-api.tiktok.com, LinkedIn Conversions API by the conversionEvents endpoint, Google Enhanced Conversions by enhanced_conversion or allow_enhanced_conversions. A match means "ok" with the list. No match is a note, never critical.

What the scan cannot see: the API itself. A server container forwarding events to Meta or Google does so without the browser's involvement, and that is exactly its purpose. The scan can only name indicators, not deliver confirmation. Whether a first-party endpoint runs is shown by the server-side tagging finding; whether Enhanced Conversions are switched on in the container, by the Google Ads finding.

Why it matters

The browser pixel measures only whom it reaches: no ad blockers, no Safari with ITP, no rejection in the banner. The Conversions API reports the conversion from the server, with the same event_id, so the platform merges pixel and server event instead of counting twice, and for campaigns optimising on conversions that is the difference between an algorithm that learns and one that guesses. Learning needs data. Whoever enables the API in the ad account alone, without checking the event matching, gets the opposite though: duplicate conversions or discarded ones. How the server container solves that cleanly is covered in the guide server-side tracking with Stape.

Common causes

Paid campaigns run, but conversion measurement hangs entirely on the browser pixel.
CAPI was activated in the ad account but sends without a consistent event_id, conversions count twice or get discarded.
Enhanced Conversions are on in the Google Ads account, but the hashed fields never come out of the tag.
The site runs no paid campaigns, then the finding is expected and not an error.

The fix

With paid campaigns running, set up the Conversions API alongside the pixel, preferably in the server container: the same event_id in pixel and server event, hashed user data for Enhanced Conversions from the dataLayer, consent state passed along. Then check the deduplication rate in Meta's Events Manager and the Enhanced Conversions diagnostics report in Google Ads. The scan will still recognise the API only by indicators afterwards; the proof lives in the ad accounts.

Matching template

GA4 and Google Ads Consent Mapping

Documents which data flows from GA4 to Google Ads and which signal governs each flow.

Get the worksheet →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

We send conversions to Meta through the server container. Why does the scan say "no indicators"?

Because a server-to-server call leaves no trace in the HTML. The scan only sees what the browser loads: the events endpoint in a script, an external_id in the pixel init, the Enhanced Conversions switch in the tag. If the Conversions API runs entirely in sGTM, the note is expected. The tracking architecture finding in the deep scan then shows the first-party endpoint the events go through.

What counts as an indicator, and what no longer does?

The events endpoint graph.facebook.com/v…/events, an fbq("init") with external_id, business-api.tiktok.com, the LinkedIn endpoint conversionEvents, and the parameters enhanced_conversion or allow_enhanced_conversions. Since September 2026, fbq("dataProcessingOptions") and ttq.load no longer count: one is Meta's US flag, the other the ordinary browser pixel, and both reported "CAPI detected" on sites without a Conversions API.

Do we need a Conversions API if the pixel works?

If you run paid campaigns, yes. The pixel loses to ad blockers, Safari ITP and everyone who rejects; the API sends the conversion from the server, with the same event_id, so Meta recognises the duplicate. Without paid campaigns the note needs no action.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint