Conversion API Explained: What It Is, How It Works, and Whether You Need One

Quick answer: A conversion API is a server-to-server connection that sends conversion events from your server directly to an ad platform instead of relying on a browser pixel. Because the data never passes through the browser, it survives the ad blockers, Safari tracking prevention, and cookie loss that cause pixels to miss 30 to 40 percent of conversions.

Search for “conversion api” and the top of Google is Meta’s developer documentation, followed by a stack of explainers from data pipeline vendors. Sitting at position seven, outranking most of them, is a Reddit thread titled “what’s the deal with conversion APIs and do i actually need one.” That thread ranks because it asks the question every marketer actually has, and none of the pages above it answer.

This post answers it. What a conversion API actually is, how the four major ad platforms implement the idea in four different ways, what happens to your data when you run one next to a pixel, and an honest framework for deciding whether you need one at all.

There is no such thing as “the” conversion API

Here is the thing the generic explainers gloss over: “conversion API” is one name for at least four structurally different systems. The phrase reads like a standard, the way “REST API” is a standard. It is not. Each ad platform built its own server-side ingestion path, with its own event model, its own matching rules, and its own constraints. The differences are not trivia. They decide what you keep, what you lose, and what breaks.

The reason the term feels like it means one thing is that the pages ranking for it are mostly written by vendors whose product abstracts the differences away, so “we support conversion APIs” appears comparable across tools when it is not. Ask which specific delivery paths a vendor implements, per platform, and the comparable claims fall apart fast.

Here is what each platform actually ships, as of August 2026:

Platform	Server-side path	Event model	Dedup key	Time constraint	What must stay in the browser
Meta	Conversions API (CAPI)	Full event stream mirroring pixel events	event_name + event_id	Website events older than 7 days are rejected	Pixel recommended for redundancy and match quality
Google Ads	Click conversion uploads + enhanced conversions	No event stream; conversions keyed to a click ID	Click ID + conversion action	Accepted through the conversion action’s click window, up to 90 days	The gtag/GTM tag if you use enhanced conversions for web
Microsoft Ads	UET Conversions API (GA late 2025)	Meta-shaped event stream	Event + transaction ID for restate/retract	eventTime must be within the last 7 days; older goes via ApplyOfflineConversions	ID sync pixel; Microsoft’s docs say audience features stop working without it
TikTok	Events API	Meta-shaped event stream	event_id	Events accepted with a limited lookback	Pixel recommended for redundancy, keyed by ttclid

Three of these look like siblings. The fourth is the giveaway. Google does not have a conversion API in the Meta sense at all. There is no endpoint where you stream Purchase events and let Google figure out the user. Google’s server-side path is a conversion upload keyed to a click ID (gclid, or gbraid and wbraid on iOS traffic), optionally strengthened with hashed customer data through enhanced conversions. If you did not capture the click ID when the visitor landed, there is nothing to upload. That single difference is why “install the CAPI” advice written for Meta translates so badly to Google, and why Google Ads conversion tracking is its own discipline.

Microsoft is the newest entrant. Its UET Conversions API went to general availability in late 2025, and it copied Meta’s shape with one sharp edge: validation rejects any event whose eventTime is more than 7 days old. A B2B conversion with a three-week sales cycle can never travel through Microsoft’s CAPI. It has to go through the older offline conversion upload path instead, the same family of API Convultra uses for its Microsoft delivery.

TikTok’s Events API is the closest thing to a straight Meta clone, down to event_id deduplication, and if you are already firing pixel events it is the most familiar migration. Our TikTok Events API setup guide walks through it end to end.

What a conversion API actually does

Strip away the platform differences and the mechanics are consistent. When a conversion happens, your server assembles an event with three kinds of information:

1. What happened. Event name, value, currency, an order or transaction ID.
2. Who did it. Hashed identifiers, almost always SHA-256 of a lowercased, trimmed email or an E.164 phone number, plus IP address and user agent.
3. Which click it came from. The click ID the platform appended to your landing URL: gclid, fbclid, msclkid, ttclid.

Your server POSTs that payload to the platform’s endpoint, the platform matches it to a user or a click, and the conversion lands in your ads account the same as a pixel-reported one. The delivery leg is only half of server-side conversion tracking; the other half is capture, and capture is where most implementations quietly fail.

The click ID is the strongest match signal on every platform, and it only exists at the moment of landing. If the script that captures it is blocked, or the ID is stored in a JavaScript-written cookie that Safari’s ITP expires after 7 days, the conversion API on the other end has nothing to match against. This is why serious implementations store click IDs in server-set first-party storage at landing time, before any of the fragile stuff runs. A conversion API without click ID capture is a delivery truck with nothing in it.

Pixel and API together: redundancy done right, or double counting done wrong

The standard architecture on Meta, Microsoft, and TikTok is not pixel or API. It is both, sending the same events, deduplicated. The pixel covers browsers where nothing is blocked and contributes match signals the server cannot see. The server event covers everything the pixel misses. The platform keeps whichever copy arrives first and discards the twin, provided the two copies carry the same event_id.

That “provided” is doing heavy lifting, and it is the part I would argue matters more than anything else on this page. A missing conversion and a duplicated conversion are not symmetrical errors. A gap makes your numbers read low. A duplicate makes them read high, and the platform’s bidding system, Advantage+ or Smart Bidding, treats the phantom copies as real outcomes and spends real budget optimizing toward them. Running pixel plus API with sloppy deduplication is the one configuration that is worse than either path alone, because it does not just misreport performance, it trains the bidder on inflated data.

The fix is boring and absolute: generate the event ID once, at the moment the conversion is created, and hand the same value to both delivery paths.

// One event ID, two delivery paths. ES module.
import { createHash, randomUUID } from 'node:crypto'

const sha256 = (value) =>
  createHash('sha256').update(value.trim().toLowerCase()).digest('hex')

export function buildPurchaseEvent(order) {
  // Reuse the ID if the order already has one; never mint twice.
  const eventId = order.trackingEventId ?? randomUUID()

  return {
    eventId, // the pixel must send this exact value as its eventID
    payload: {
      event_name: 'Purchase',
      event_time: Math.floor(order.paidAt.getTime() / 1000),
      event_id: eventId,
      action_source: 'website',
      user_data: {
        em: [sha256(order.email)],
        client_ip_address: order.ip,
        client_user_agent: order.userAgent,
        fbc: order.fbc ?? undefined,
      },
      custom_data: {
        currency: order.currency,
        value: order.total,
        order_id: order.id,
      },
    },
  }
}

Persist the event ID on the order the first time you mint it, and only mark the event as sent after the platform returns a success response, so a timeout stays retryable without creating a second ID. On Meta, you can watch deduplication working in Events Manager: the event match quality score tells you how well your identifiers are matching, and the event breakdown shows which copies arrived from the browser, the server, or both. The full walkthrough is in our Meta CAPI setup guide.

Google is the exception to all of this, and it is the pleasant kind. Because there is no event stream, there is no duplicate stream to reconcile. Click conversion uploads keyed to a gclid slot into the conversion action directly, and offline conversion tracking has worked this way for years.

Do you actually need one?

The honest answer to the Reddit question is: it depends on where your conversions complete and how much you spend, not on a scary percentage from a vendor page. Here is the decision, by situation:

Your situation	Verdict	Why
Ecommerce with an off-site payment gateway	Yes, first in line	The buyer converts on a page your pixel never loads on. No browser fix reaches this.
Meaningful spend on Meta or TikTok, standard checkout	Yes, as redundancy	Signal loss from blockers and ITP is real; dedup makes both-paths strictly better than either.
Lead gen with client-rendered forms	Yes, but fix capture first	If the same JavaScript that creates the lead also reports it, one blocked script loses both. Move the form handler server-side, then add delivery.
B2B with conversions weeks after the click	Yes, but not the real-time kind	Meta and Microsoft both reject stale events at 7 days. You need the offline upload paths, keyed to click IDs you captured at landing.
Small budget, one platform, same-session conversions	Not yet	Measure your gap first. If reported conversions track your backend closely, spend the effort elsewhere.

If you land in a “yes” row, you have three ways to get there: build direct integrations against each platform’s API, run a server-side tag manager and maintain it, or use a managed layer that does the capture and delivery for you. The right choice depends on engineering appetite, and we have laid out the tradeoffs in our guide to what server side tracking is and how the approaches compare.

What a conversion API does not fix

Anyone selling you a conversion API as a cure-all is selling. It does not fix consent: a visitor who declines tracking is out of scope for every delivery path, browser or server. It does not fix a click ID that was never captured, which is why the capture side deserves more attention than the delivery side gets. It does not fix a conversion action that was misconfigured in the ads account, and it will faithfully deliver events to a broken goal. And it does not create demand. It recovers the record of conversions that already happened, which repairs your measurement and your bidding signal, not your product-market fit. If you want to understand the size of the gap it can close, start with why you’re losing conversion data in the first place.

Where Convultra fits

Convultra is the managed-layer answer. One line of JavaScript captures gclid, gbraid, wbraid, fbclid, and msclkid into server-set first-party storage at landing, stitches conversions back to clicks even when the buyer detours through a payment processor redirect, and delivers server-side to each platform through its native conversion API path: Conversions API events with event_id deduplication on Meta, click conversion uploads with enhanced conversions on Google Ads, and offline conversion uploads keyed to msclkid on Microsoft Ads. Every conversion shows a per-platform delivery status you can read off a dashboard, so “did it actually send” stops being a log-diving exercise.

Where Convultra is the wrong tool: if you need arbitrary in-flight event transformation, enrichment from internal APIs mid-stream, or delivery to bespoke destinations beyond the major ad platforms, a server-side tag manager you administer yourself is the better fit. Most advertisers do not need that, which is rather the point.

FAQ

What is a conversion API?

A conversion API is a server-to-server integration that sends conversion events from your server directly to an ad platform, bypassing the browser. It exists because browser pixels lose a meaningful share of conversions to ad blockers, Safari and Firefox tracking prevention, and off-site checkout flows.

Is a conversion API the same thing as server-side tracking?

It is the delivery half. Server-side tracking covers both capturing the click and visitor data on your own infrastructure and delivering conversions to platforms. A conversion API is the delivery mechanism each platform exposes; without solid capture, it has nothing useful to send.

Do I still need the pixel if I use a conversions API?

On Meta, Microsoft, and TikTok, yes. Platforms recommend running both paths with shared event IDs so they deduplicate, and some features depend on the browser side: Microsoft’s audience targeting requires the client-side ID sync, and Meta’s match quality benefits from browser signals. Google is different because its server path supplements the tag rather than mirroring it.

Does a conversion API work without cookies?

Delivery works without third-party cookies entirely. Matching still needs something: a click ID captured at landing or hashed identifiers like email. First-party, server-set storage of click IDs is what makes cookieless delivery reliable, and consent requirements apply to server events exactly as they do to pixels.

How is Google’s version different from Meta’s CAPI?

Meta accepts a stream of events and matches them to users. Google accepts conversions keyed to a click ID it issued, uploaded into a specific conversion action, optionally enriched with hashed customer data via enhanced conversions. If the click ID was not captured, there is nothing to upload, so capture matters even more on Google.

How many conversions will a conversion API recover?

It depends on where your losses are. Sites with off-site payment gateways and heavy desktop traffic see the largest gaps, since ad blockers live on desktop. Measure your own gap by reconciling platform-reported conversions against backend orders over a closed window before trusting any vendor’s recovery percentage, including ours.

Get every conversion counted

Convultra gives you the capture and the delivery in one line of JavaScript, with per-conversion delivery status across Google Ads, Meta, and Microsoft Ads, and 95 to 98 percent tracking accuracy. Start free and compare a week of Convultra data against your backend before you believe anyone’s percentages, including ours.