Send conversion events from your server, not just the visitor's browser. Every platform, one framework: install the event call, gate it on consent, deduplicate against the pixel, verify it landed.
A client-side pixel fires from the visitor's browser and depends on that browser cooperating. A growing share of them do not.
Tell us which platform's conversion data looks light, and we will check whether the gap is dedupe, consent gating, or a missing server-side event entirely.
The server-side event call to the platform's Conversions/Events API, matched to the correct event schema (event name, parameters, hashed customer data where required).
The event is checked against the visitor's recorded consent state before it is sent - not filtered after the fact. This is wired to the consent management layer (ot.webclat.com covers OneTrust specifically) rather than bolted on.
The server event and the client pixel event for the same action carry a shared event ID (or platform-equivalent) so the ad platform counts one conversion, not two. Getting this wrong is the single most common CAPI mistake - it inflates conversion counts rather than recovering lost ones.
Confirmed in the platform's own diagnostics tool - not assumed from a 200 response on our own endpoint. See the verification method on the homepage for the full checklist.
Facebook and Instagram - the full implementation guide, dedupe logic, and platform variants (Shopify, WooCommerce, server-side GTM).
Read →Server-side event delivery for TikTok Ads campaigns, including the Shopify integration.
Read →Setup via GTM and GA4, plus offline conversion upload to Google Ads.
Read →B2B conversion delivery for high-CPC LinkedIn campaigns, plus offline conversions.
Read →Server-side conversion events for X Ads.
Read →Server-side event delivery for Snapchat Ads.
Read →Server-side conversion tracking for Pinterest Ads.
Read →Where a gateway product (Stape, a CAPI Gateway) fits versus a custom build - and when we recommend against buying one.
Read →A Conversions API is a server-to-server connection that sends conversion events (a purchase, a lead, a sign-up) from your own server directly to an ad platform, instead of relying only on a browser-based pixel. It exists because browsers increasingly block, delay, or strip the client-side pixel calls that used to carry this data.
Yes, if you want accurate conversion counts. A pixel-only setup depends on the visitor's browser and network cooperating - ad blockers, Safari's Intelligent Tracking Prevention, iOS App Tracking Transparency opt-outs, and slow page loads before the pixel fires all cause silent data loss. CAPI runs from your server, which does not depend on the visitor's browser at all, and is meant to run alongside the pixel with deduplication, not replace it.
It depends on where your event data already lives. If you run server-side Google Tag Manager or a CDP with the event already centralized, a single-platform CAPI implementation is comparatively fast. If we are building event capture from scratch, it takes longer and the estimate should reflect that discovery work - we scope this per engagement rather than quoting a fixed timeline before seeing your stack.
The seven covered here (Meta, TikTok, Google, LinkedIn, X, Snapchat, Pinterest) are where measurable implementation demand and CPC data point today. If you need a platform not listed, ask - the underlying engineering pattern (install, consent-gate, dedupe, verify) applies to any platform with a server-side event API.
Send us your ad spend split across platforms and we will tell you where a missing or broken CAPI implementation is costing you the most measured conversions.
Talk To The Practice