Meta CAPI for apps: what it is and how to implement it

Short answer: Meta’s Conversions API (CAPI) lets a server report events such as subscription renewals and trial conversions that occur while an app is closed. First check what your SDK, MMP or subscription platform already sends. App events need an app-linked dataset and action_source: app; actual website events use website. If sources overlap, coordinate event IDs and names or disable duplicate reporting. Otherwise, apparent improvements in cost per conversion may be double-counting.

What is Meta CAPI?

The Conversions API is a server-to-server connection. It can send app, website, offline and messaging events into Meta Events Manager (Meta for Developers: Conversions API for app events).

Meta also supports the SDK and App Events API, including MMP integrations. CAPI is another event-delivery route, not a replacement for attribution or every SDK function. Check your partner’s current integration before adding it: an MMP or subscription service may already report backend events, and another connection may add duplicates rather than missing data.

Does an app need CAPI if it already has the SDK or an MMP?

Not always. Audit which events arrive accurately, with the required identifiers, value and currency. CAPI is worth considering when it fills a real gap, such as:

• Subscription events. Renewals and trial conversions are processed by the App Store or Google Play, often when the app is closed. Your backend or subscription platform knows about them; the device may not.
• Web purchases. A web-to-app funnel can need website event reporting alongside app events. Keep the sources and identifiers correct; a web purchase does not become an app event because the product is an app. See how web-to-app funnels change SKAN and Meta optimization on iOS.
• Consistent subscription revenue reporting. A billing integration can attach transaction values from its own records. Define whether those values are gross or net of fees and reconcile them with your financial data; do not assume a refund reverses an earlier Meta event.

How do you implement CAPI for app events?

The main checks in Meta’s app events documentation are:

1. Link a dataset to your app. Meta requires this before you can send app events through CAPI, and only one app can be linked to a dataset.
2. Use the actual source. Send action_source: app for app events and website for website events. Include the event name and time, plus value and currency for revenue events, following the relevant event schema.
3. Coordinate event_id when sources overlap. Meta requires it to set up deduplication; the same event needs the same ID and name across sources.
4. Fill app_data. App events require advertiser_tracking_enabled, reflecting the applicable tracking permission, and extinfo, an ordered device array beginning i2 for iOS or a2 for Android. Keep the documented field order, include the operating-system version and leave unavailable optional positions empty.
5. Send permitted identifiers in user_data. These can include madid (IDFA or Android advertising ID), anon_id and the client IP address. Meta says not to hash those three. A server connection does not remove Apple’s tracking-consent requirements.

You can build this yourself or use a subscription platform. RevenueCat recommends CAPI for its Meta integration, using a Dataset ID and Conversions API token. Its default mapping sends trial starts as StartTrial and trial conversions, initial subscription purchases and renewals as Subscribe. Keep the Meta SDK for installs and relevant on-device events. RevenueCat’s server integration does not configure SKAdNetwork or Aggregated Event Measurement, or update SKAdNetwork conversion values.

Before enabling it, decide which source owns each event. RevenueCat and the Meta SDK do not automatically share event IDs, so merely enabling both does not establish deduplication.

How does deduplication work, and why can your CPA be lying to you?

If the SDK, your MMP and CAPI report the same purchase, Meta needs a way to recognize one event. For app events, Meta supports deduplication across those routes using matching event_id and event_name values. Incorrect IDs can cause incorrect deduplication (Meta for Developers). Installs are handled separately: Meta’s app-event documentation describes keeping the first install in a 90-day window and dropping subsequent install events.

When duplicate events are counted and attributed, reported cost per conversion can fall without any business improvement. To avoid that:

• One source per event where you can. RevenueCat advises disabling overlapping Meta SDK purchase tracking unless you explicitly manage deduplication. Keep non-overlapping SDK events, such as installs.
• Where two sources must send the same event, generate one ID at the moment of the event and pass it to both.
• Reconcile weekly. Compare raw event delivery with your transaction records, then check attributed campaign results separately. Events received and conversions attributed are different counts; a discrepancy is a reason to investigate, not proof of duplication.

For website events from a web-to-app funnel, Meta deduplicates pixel and CAPI events sent to the same pixel with matching event_id and event_name within 48 hours of the first event (Meta for Developers: deduplication).

Does event match quality apply to app events?

Meta’s current help page and developer guidance limit the 0-to-10 event match quality score to website events. For app events, check event delivery, required fields, permitted identifiers and deduplication. A successful API response does not prove that an event matched a user, received attribution or qualified for optimization.

Will CAPI lower your mobile app CPA?

CAPI can improve the completeness of the events available for measurement and optimization. That does not guarantee lower acquisition costs. Judge business outcomes in your own transaction or attribution data, not just an increase in conversions reported by Meta. A before-and-after comparison is a useful check, but it does not isolate CAPI’s effect from changes in creative, spend or demand. Do not promise a universal percentage improvement.

Once events are clean, creative is the main lever we would work on: new directions tested through several ads across angles, hooks and formats. See how to measure creative diversity in your Meta account. For the wider iOS measurement picture, start with how to fix mobile attribution on iOS, and for which event to optimize toward, what AEO is in Meta ads.

Frequently asked questions

What is Meta CAPI? The Conversions API is Meta’s server-to-server route for sending conversion events, from web, app, store or messaging, into one dataset in Events Manager. For apps it complements the Meta SDK and your MMP rather than replacing them.

Does Meta CAPI work for mobile apps? Yes. Follow Meta’s app-event schema: use an app-linked dataset, action_source: app and the required event and app_data fields. If the event is also sent through another source, coordinate event_id and event_name for deduplication.

Do I need CAPI if I use an MMP? Check what your MMP already sends, including backend events. Add CAPI where it solves a reporting or integration need, then coordinate overlapping events. Renewals and trial conversions are possible use cases, not proof that every MMP setup is missing them.

Why does Meta show more conversions than my MMP? Duplicate event delivery is one possible cause, but raw events and attributed campaign conversions are different measures. First compare like-for-like counts and check event diagnostics. Where sources overlap, disable duplicate tracking or send matching event IDs and names.