Conversion API (CAPI)
A Conversion API (CAPI) is a server-to-server interface that sends marketing events directly from your backend to an ad platform such as Meta, TikTok, or Google. It bypasses the browser to deliver more complete and reliable conversion data.
Key takeaways
- Each event carries a name, timestamp, action source, hashed user data and custom data.
- Requests authenticate with an access token bound to the ad account, not to a browser.
- Match rate rises with every additional hashed identifier and with the stored click identifier.
- Events arriving outside the platform's backdating window are recorded but influence no bidding.
- Unmatched events fail silently, so integrations can look healthy while half the data disappears.
In depth
What travels over a Conversion API is a small, strictly shaped payload. Each event carries a name, a timestamp, an action source that says whether it happened on a website, in an app, by phone or in a shop, a user_data block of hashed identifiers, and a custom_data block with value, currency and anything else you want reported. The call is authenticated with an access token tied to the ad account, so the platform trusts your server the way it once trusted a browser tag.
Everything hinges on how many usable identifiers you can attach. Email and phone hashed with SHA-256 match hardest; first name, city, postal code and country add weight; the click identifier captured at landing and the browser cookie value, forwarded from your database, lift matching further still. Timing matters as much: platforms accept events only inside a backdating window, and a nightly batch that arrives days late may be recorded yet fall outside the attribution window, so it never influences bidding.
The natural use is to report the events the browser cannot know. A CRM webhook fires when a deal moves to sales-accepted, and your service posts that stage change with the original click identifier stored at capture. Phone bookings and offline sales enter the same way with a matching action source. In a scorecard funnel the scoring happens after submission, so the qualified event, carrying the tier as value, is emitted from the backend rather than guessed at from a thank-you page URL.
An event with weak identifiers is not rejected loudly; it is accepted, left unmatched and quietly excluded from reporting, which is why teams often believe the integration works when half of it does not. The API also cannot create identity where none exists: traffic that never clicked an ad has nothing to attribute to. And a deep-funnel event that occurs only a few times a week may be too sparse for the platform's optimisation to learn from at all.
Example in practice
How to measure it
Start with the platform's own diagnostics. Every major implementation exposes a test event tool that echoes back what it parsed, a match quality indicator per event, and a warning list for missing or malformed parameters. Send a test conversion for a contact you can identify, confirm it appears with the fields you expected, then check the share of production events flagged as unmatched over the following week.
Then measure the outcome, not the plumbing. Compare platform-reported conversions against the same events counted in your database for the same window, and track the ratio as identifiers are added. Watch the delivery side too: after switching optimisation to a server-reported event, cost per that event and the volume of downstream accepted leads are the pair that tells you whether the richer signal actually improved buying.
Common mistakes
The commonest technical error is normalising badly before hashing. Platforms expect lowercase, trimmed values in a defined format, so a phone number sent with spaces or a country prefix inconsistently applied hashes to something the platform will never match. Follow each platform's normalisation rules exactly and test with a known contact whose record you can verify. Sending an already-hashed value through a second hashing step produces the same silent failure and is easy to introduce during a refactor.
The second is choosing an event that nobody downstream cares about. Teams wire up the API in a week, send every page view server-side, and end up optimising for the same shallow action they had before, only more reliably. Decide which single event best predicts revenue, send that one with a value, and keep the rest for reporting. Firing conversions from a CRM stage that a sales rep sets by hand also introduces lag and bias into the optimisation signal.
Frequently asked questions
How is CAPI different from server-side tracking?
Server-side tracking is the general approach of collecting events on your own server. CAPI is a specific platform interface, like Meta's or TikTok's, that receives those server events, so CAPI is typically one destination of a server-side setup.
Why do I need to send hashed identifiers to CAPI?
Hashing email or phone numbers lets the platform match a conversion to a user without exposing raw personal data. It improves match rates while keeping the data protected in transit.
Can CAPI double-count my conversions?
Yes, if the pixel and CAPI report the same event without a shared event_id. Always set a consistent event_id so the platform can deduplicate and count each conversion only once.
Is a Conversion API the same as server-side tracking?
Not quite. Server-side tracking describes collecting events on infrastructure you control, while a Conversion API is one advertising platform's server-to-server endpoint for receiving them. You can call a Conversion API directly from your application without any server container, and you can run server-side collection that forwards to analytics tools which have no such API at all.
Which data do I have to send for a good match?
Hashed email and phone number do the most work, followed by first name, last name, city, postal code and country. If you stored the click identifier from the landing URL and the platform's browser cookie value, forward both, because they match without relying on personal data at all. More correctly formatted fields consistently produce a higher match rate.
How late can I send a conversion?
Each platform defines a backdating window, commonly a few days, after which an event is refused. Being accepted is not the same as being useful: an event that lands after the attribution window closes will not be credited to the ad interaction that caused it. For offline conversions, send as soon as the record is created rather than in a weekly batch.
Do I need both the pixel and the Conversion API?
Running both is the recommended pattern for web events. The browser tag supplies signals the server cannot see, the API covers events the browser loses, and deduplication on a shared event identifier stops double counting. For genuinely offline events such as a phone sale there is no browser side, so the API is the only path available.
Does the Conversion API violate privacy rules?
Not inherently, but it does not exempt you either. You are sending personal data to an advertising platform, which needs a lawful basis, transparent disclosure, and respect for withdrawn consent. Hashing reduces exposure without making data anonymous, since the platform matches on those hashes. Suppress events for users who opted out rather than sending them and hoping the platform filters.
Why did my conversion counts fall after enabling the API?
Usually because deduplication is now working. Before the integration, one path reported; afterwards two paths report and the platform collapses matching pairs into one conversion, which corrects a previously inflated number. Falls can also come from stricter match requirements, since events without usable identifiers are dropped instead of being counted the way a browser tag counted them.