The Conversions API is Meta's server side channel for conversion data. Where the Meta Pixel reports events out of the visitor's browser, the API lets your web server, your ecommerce platform or a customer data tool send the same events straight to Meta over a direct connection, with a customer identifier such as a hashed email attached.
Meta recommends running both paths at once. Each event carries an event ID, and when the pixel and the server report the same purchase, the platform deduplicates them and keeps one. The browser event is fast and rich in context; the server event survives ad blockers, expired cookies and users who opted out of app tracking.
Other platforms have equivalents, such as offline conversion imports in Google Ads and the TikTok Events API, and the reasoning is the same everywhere: as browsers share less, advertisers have to report outcomes themselves if they want the bidding system to see them.
Mechanics
How server side events travel to Meta
The setup has three parts. A source: your store platform, a tag management server, a CRM or your own backend, wherever the truth about an order or a lead lives. A connection: Shopify, WooCommerce, HubSpot and many others offer a native integration, and anything else can post events through a server side tag container or a short piece of code. And a payload: the event name, a timestamp, the value, the event ID that matches the pixel event and whatever customer details you are allowed to send, hashed before they leave your system.
Meta then matches the customer details to an account, checks whether that person saw or clicked one of your ads inside the attribution window, and credits the campaign. The Event Match Quality score in Events Manager tells you how well your payload is matching; a low score usually means you send an event ID and a value but no email, phone or click ID.
Because the server can report events that happen after the visit, such as a lead that turned into a customer three weeks later, the API also lets you feed real outcomes back into bidding rather than form fills.
Example
A worked example for a meal kit company
Suppose a subscription meal kit company spends 20,000 a month on Meta and tracks signups with the pixel only. Ads Manager shows 400 signups, a cost per signup of 50, while the finance team counts 560 new subscribers in the same period and a customer survey attributes roughly 65 percent of them to social ads, or about 364.
The gap is the visitors the pixel never saw: ad blockers, iOS opt-outs and a checkout that runs on a separate domain. After the company connects its subscription platform to the Conversions API with hashed emails and a shared event ID, the next month reports 520 signups on the same spend, a cost per signup of about 38.50, with deduplication removing the overlap.
Nothing about the ads changed. The campaign was always performing at that level; the reporting was blind to a third of it. With the fuller signal the bidding system also had 30 percent more examples of a real subscriber to learn from, and the following month's cost per signup fell a little further.
Use
When you need the Conversions API
- You need it when Meta ads are a meaningful part of your spend and the reported results are clearly lower than what your order system or CRM shows.
- You need it when a large share of your customers use iPhones, since app tracking transparency removed most of those users out of browser based reporting.
- It pays off for lead generation businesses that want to send qualified leads or closed deals back to Meta, so the campaign optimizes for revenue rather than form fills.
- It changes little for a small site that runs awareness campaigns only, where the difference between 800 and 1,000 reported page views affects no decision.
- Treat the reported lift as recovered visibility, not new performance; the ROAS looked worse before because the data was incomplete.
Watch out
Common mistakes with the Conversions API
- Sending server events without the event ID that the pixel uses, so every purchase is counted twice and the reported cost per result drops for the wrong reason.
- Omitting customer information such as a hashed email or the click ID, which leaves Event Match Quality low and most events unattributed.
- Turning off the pixel after connecting the API, which removes the browser context that server events lack and weakens both audiences and matching.
- Sending test events into the production data set, so a week of internal checkout tests shows up as a spike in purchases on the ads dashboard.
- Assuming a plugin's one click setup is complete, without opening Events Manager to confirm that events arrive, deduplicate and match at a reasonable rate.