The Conversions API (CAPI) is a server-to-server endpoint an ad platform exposes for receiving conversion events directly from a brand’s backend, bypassing the browser-side pixel. Meta’s is the canonical case; Google Ads Enhanced Conversions, TikTok Events API, Pinterest Conversions API, and Snap Conversion API are the same pattern.
CAPI restores events the browser couldn’t deliver. It does not restore events the user refused. The two failure classes get conflated. Delivery failures — ITP, ad-blockers, page unloads, network errors — happen to users who consented; the backend has the order and sends the event server-side regardless of what the browser did. Consent denials are different in kind: the visitor opted out via the CMP or the iOS ATT prompt, and the lawful basis is missing on every channel. That belongs to Consent Mode and ATT, not CAPI.
The payload is small: hashed email, hashed phone, the click ID from the ad referral (fbclid, gclid), plus value, currency, and content IDs. An event_id shared with the pixel send lets the platform deduplicate when the same event arrives twice. The combined signal feeds the platform’s attribution model, ML optimizer, and audience builder without double-counting.
CAPI is not server-side tagging. Server-side tagging is the infrastructure — a tagging server the brand controls, typically GTM Server-Side or Stape — and CAPI is one destination it forwards to. Shopify’s native Meta sales channel sends to CAPI without a tagging server; conversely, a tagging server can run with CAPI as one destination alongside GA4 and the warehouse.
Match quality is the precondition. Without fbclid/gclid, hashed email, or hashed phone, the platform cannot tie the event to a user or ad click, and match rates collapse — which is why CAPI rides on first-party data.