Adapty to Meta CAPI: purchase webhooks, profile attributes, and event_id
Updated July 10, 2026 · 10 min read
Adapty should be treated as a verified subscription event source, not as a UI paywall callback. The webhook knows when a purchase, renewal, or trial state actually changed.
The implementation challenge is making sure Adapty profile attributes contain the attribution envelope collected before the user purchased, then reusing that envelope inside the CAPI event.
Setup, end to end
- 1In Meta Events Manager, note the dataset (pixel) ID and generate a Conversions API access token, and confirm it's the dataset your ad account optimizes on.
- 2Capture Meta click identity in-app at checkout and attach it to the Adapty profile (as custom attributes) so the server event can carry it.
- 3Forward purchases from a trusted server context, such as an Adapty webhook or server integration, instead of from the app. A crash after purchase should not skip the event.
- 4On each verified purchase and renewal, build a CAPI Purchase with the price and ISO currency, 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 Purchase event so Meta deduplicates to a single conversion.
- 6Verify in Test Events, then raise Event Match Quality by filling any missing identity parameters.
Profile attributes as attribution bridge
Attach attribution data to the Adapty profile before paywall conversion. The webhook can then recover identity without browser or device cookies.
await adapty.updateProfile({
zoruko_visitor_id: visitorId,
meta_event_id: eventId,
meta_fbp: identity.fbp ?? "",
meta_fbc: identity.fbc ?? "",
landing_session_id: landingSessionId,
});CAPI event selection
const eventName =
webhook.eventType === "trial_started" ? "StartTrial" :
webhook.eventType === "subscription_started" ? "Subscribe" :
webhook.eventType === "subscription_renewed" ? "Purchase" :
webhook.eventType === "non_subscription_purchase" ? "Purchase" :
undefined;The mistakes that break it
- Firing from the app's purchase callback instead of Adapty's verified server event.
- Reporting trial starts and paid conversions as one event, or sending renewals at the trial price.
- Dropping the click identity, which tanks match quality even though the event 'arrives'.
- Mismatched or missing event IDs across client and server, causing double counting or discards.
- Token pointing at a different Meta dataset than the ad account reads.
Frequently asked questions
Why isn't my Adapty + Facebook integration tracking purchases?
Usually the purchase is verified in Adapty but never forwarded to Meta's Conversions API, or it's forwarded without a value, currency, or click identity. Fire a CAPI Purchase from an Adapty webhook on each verified purchase and renewal, with the real amount and hashed identifiers.
Should I send Adapty purchases to Meta from the client or the server?
From the server. Adapty's webhook fires on verified purchases, so a crash or backgrounding after checkout can't skip it. Keep a client event only for identity, deduplicated with a shared event ID.
How do I track Adapty subscription renewals in Meta?
Handle the renewal webhook event and send a CAPI Purchase with the renewal's actual price and currency, not the trial or intro price. Keep trials and paid conversions as separate events.
Related guides
Not sure which signal path is breaking?
Zoruko audits your web and mobile code for broken Meta and TikTok signal chains, then ships each fix as a pull request you review.