RevenueCat + Meta Conversions API: the complete setup guide
Updated July 10, 2026 · 8 min read
RevenueCat knows exactly when a purchase or renewal is verified, which makes it the right place to trigger a server-side Meta Conversions API (CAPI) event. The goal: every validated purchase reaches Events Manager with a real value, currency, and enough identity for Meta to attribute it — deduplicated against any client-side event.
This guide walks the setup end to end and the mistakes that usually break it.
Setup, end to end
- 1In your Meta Events Manager, note the dataset (pixel) ID and generate a Conversions API access token. Confirm the dataset is the one your ad account actually optimizes on.
- 2Capture Meta click identity at checkout: read the click identifiers available on the device and attach them to the RevenueCat customer as subscriber attributes so the server event can carry them.
- 3Send purchases to Meta from a trusted server context — a RevenueCat webhook handler or a server integration — not from the app, so a crash after purchase can't skip it.
- 4On each INITIAL_PURCHASE and RENEWAL event, build a CAPI Purchase with the price and ISO currency, the hashed customer identifiers, and the captured click identity.
- 5Generate one event ID per purchase and send it on both the CAPI event and any client-side Purchase event, so Meta deduplicates to a single conversion.
- 6Verify in Test Events, then check Event Match Quality on the Purchase event and raise it by adding any missing identity parameters.
The mistakes that break it
- Firing the event from the app's success callback instead of the verified server event — post-purchase crashes then silently drop conversions.
- Sending renewals with the original trial price (often $0) instead of the renewal amount, so revenue optimization sees nothing.
- Omitting the click identity, which tanks Event Match Quality and attribution even though the event 'arrives'.
- Using a different event ID (or none) on client vs server, causing double-counting or discarded events.
- Pointing the token at the wrong Meta dataset, so events land somewhere your ad account never reads.
How this maps onto the concepts
RevenueCat is your server-side source of truth; the CAPI call is the server path from the client-vs-server model. You still want a client-side Purchase event for identity — deduplicated with the shared event ID.
If you also run Adapty, Superwall, or your own receipt validation, the same pattern applies: fire CAPI from wherever the purchase is verified, carry identity, deduplicate.
Frequently asked questions
Why isn't my RevenueCat + Facebook integration tracking purchases?
Usually because the purchase is verified in RevenueCat but never forwarded to Meta's Conversions API, or it's forwarded without a value, currency, or click identity. Fire a CAPI Purchase from a RevenueCat webhook on each verified purchase and renewal, with the real amount and hashed identifiers.
Should I send RevenueCat purchases to Meta from the client or the server?
From the server. RevenueCat's webhook fires when a purchase is actually verified, so a crash or backgrounding after checkout can't skip it. Keep a client-side event only for identity, deduplicated with a shared event ID.
How do I track subscription renewals in Meta with RevenueCat?
Handle the RENEWAL webhook event and send a CAPI Purchase with the renewal's actual price and currency. Don't reuse the trial or intro price, and keep trials and paid conversions as separate events.
How do I keep Meta from double-counting RevenueCat purchases?
Assign one event ID per purchase and send it on both the server-side CAPI event and any client-side Purchase event. Meta deduplicates on that ID and counts the conversion once.
Related guides
Not sure which of these is breaking your app?
Zoruko audits your app code for broken Meta and TikTok signal chains — free — and ships each fix as a pull request you review.
Run a free audit