Meta’s Conversions API (CAPI) is a server-side way to share app conversion events with Meta. Instead of relying only on events sent from the device through the Facebook SDK, your server (or your Mobile Measurement Partner) sends the same events directly to Meta. The point is signal completeness: after Apple’s App Tracking Transparency (ATT) framework, device-level signal is partial and inconsistent, and Meta’s optimization and reporting can only act on the events it actually receives. A server-side path gives Meta a more complete and more durable record of what happened, which is what its algorithm uses to find and value users. CAPI does not replace your SDK, your MMP, or SKAdNetwork. It complements them.
Page Contents
What is the Conversions API?
The Conversions API is a server-to-server channel for sending events to Meta. A conversion (a registration, a trial start, a subscription, a purchase) is recorded by your backend and posted to Meta’s API, rather than being inferred solely from an on-device SDK call.
The two paths capture different things:
- SDK (on-device): good at real-time, in-app context like app opens and session signals, but subject to device-level consent and platform restrictions.
- CAPI (server-side): good at events your backend already knows are true (a confirmed purchase, a server-validated subscription), and not dependent on the device sharing them.
Run together, with deduplication, they give Meta one clean record per event from the most reliable source available.
Why does server-side signal matter after ATT?
Since ATT, a meaningful share of iOS users do not grant tracking permission, and device-level signal degrades as a result. The exact loss varies by app, audience, and geography, so treat any single number you see with skepticism. The qualitative reality is consistent: the SDK alone no longer sees every conversion, and Meta cannot optimize toward outcomes it never receives.
Server-side signal helps because it is:
- More complete: events recorded on your backend reach Meta even when the device path is restricted.
- More durable: a confirmed server event is less fragile than an inferred device event, and less likely to silently drop.
- More trustworthy for optimization: richer, cleaner conversion input generally helps Meta’s models learn and allocate budget more sensibly.
This is signal quality work, not a growth hack. The honest framing is that CAPI restores some of the visibility ATT removed; it does not manufacture performance on its own.
How does CAPI fit alongside the SDK, MMP, and SKAN?
On a mobile app, several measurement systems run in parallel, each answering a different question:
- Facebook SDK: on-device event capture and real-time app context.
- MMP (AppsFlyer, Adjust, Singular): your attribution source of truth, and often the easiest place to switch on CAPI forwarding without custom engineering.
- CAPI: the server-side feed of events into Meta for optimization and reporting.
- SKAdNetwork (SKAN): Apple’s privacy-preserving attribution, with aggregated, delayed, conversion-value-based data and no user-level detail.
These do not reconcile event-for-event, and trying to force them to match is a common time sink. SKAN and CAPI in particular use different methodologies and will report different numbers for the same campaign. Use SKAN for directional iOS attribution and CAPI for feeding Meta’s optimization. Many teams enable CAPI through their existing MMP first, because it captures most of the value with minimal engineering, then add a direct server-to-server integration later if they need custom parameters or tighter control. For how the privacy-preserving side works, see what SKAdNetwork is and how it works.
What are the common failure modes?
Most CAPI problems are data quality problems, not infrastructure problems. The integration “works” (events are received) while quietly sending Meta a distorted picture. Watch for:
- Missing deduplication: running SDK and CAPI together without a shared event identifier means Meta counts the same conversion twice. Inflated conversions make CPAs look artificially low and can mask real performance problems. The fix is to send the same event identifier from both the SDK call and the server event so Meta keeps only one.
- Event mismatch: mapping internal events sloppily to Meta’s standard events, or leaning on custom events where a standard event exists. Meta’s optimization is built around its standard events, so imprecise mapping weakens the signal you worked to recover.
- Poor user-data quality: matching depends on the identifiers you attach. Personally identifiable fields must be normalized and hashed (SHA-256), phone numbers in E.164 format, currency in ISO 4217. A single broken or unhashed field can silently degrade match quality, often after an unrelated code deploy.
- Stale or missing values: events sent long after they happen, or purchase events sent without a revenue value, undercut value-based optimization. Send events close to real time, and include the actual transaction value and currency.
The throughline: validate continuously. Use Meta’s Events Manager and its test-events tooling to confirm events arrive, parameters parse, matching looks healthy, and deduplication is actually deduplicating before and after you go live. A simple ongoing check is comparing your own server-side event counts against what Meta reports; a persistent gap in either direction is worth investigating.
How does this connect to the rest of your Meta program?
Cleaner signal is an enabler, not the whole job. Once CAPI is stable, it can support deeper-funnel optimization, value-based bidding when you send reliable revenue, and better-populated retargeting audiences (including users the SDK missed). But signal infrastructure only pays off when the creative and account structure on top of it are sound. The strongest signal in the world cannot rescue weak creative, which is where most app-campaign performance is actually won or lost; see our mobile ad creative strategy guide. Change one thing at a time: it is hard to read CAPI’s impact if you restructure campaigns in the same window.
Frequently asked questions
Does CAPI replace the Facebook SDK?
No. It complements it. The SDK still captures on-device, real-time context that a server cannot replicate. CAPI adds a durable server-side record. The recommended setup is both, running together with deduplication.
Does CAPI work for Android, or only iOS?
Both. On iOS its primary value is recovering signal lost to ATT non-consent. On Android it adds redundancy and server-validated events, which helps matching and reporting reliability.
Can I use CAPI without an MMP?
Yes. You can build a direct server-to-server integration with Meta’s API. It takes more engineering but gives you full control of the payload. Many teams start with their MMP’s built-in connector and move to a direct integration as needs grow.
Will CAPI change my SKAdNetwork setup?
No. CAPI and SKAN operate independently. CAPI sends server-side events to Meta for optimization and reporting; SKAN runs through Apple’s privacy framework with its own conversion-value mapping. Changing one does not alter the other.
Methodology note
This article is a qualitative, conceptual explanation of what Meta’s Conversions API does and why server-side signal matters for app campaigns. It deliberately contains no performance statistics, benchmarks, match-rate figures, cost-per-action or return-on-ad-spend numbers, or setup-time estimates. The size of ATT-driven signal loss, and the impact of any CAPI implementation, vary by app, audience, geography, and configuration, and should be measured in your own account rather than assumed from a generic figure. For exact API requirements, event schemas, identifier and hashing rules, and current limits, consult Meta’s official Conversions API documentation, which is the authoritative and up-to-date source.
