CONNECTIONS / AppsFlyer
AppsFlyer's Push and Pull API, sent to every ad platform
Whether the setup runs AppsFlyer's real-time Push API or a scheduled Pull API report, the attribution already exists. Signals turns either one into hashed app conversions for Meta, Snap, and TikTok, filtered against AppsFlyer's own fraud verdicts.
- ● appsflyer :: signals live
- > push postback install af_status=non_organic
- > pull api af_purchase value=68.00 AED
- hash sha256(email,phone) skan=cv_12
- route meta · snap · tiktok
- ✓ 3 destinations synced · match 81%
The signal AppsFlyer yields.
Every kind of signal that moves between AppsFlyer and the platforms, through one hashed, deduplicated route.
- App conversions
- Every install and event AppsFlyer's Push API forwards reaches Meta, Snap, and TikTok server-side the same run it lands.
Pick your platform. Every use case for it, in one place.
Every way AppsFlyer data moves, grouped by platform and ranked by how many use cases AppsFlyer supports.
Meta 1 
Snap 1 
TikTok 1 From authorization to delivered signal.
-
Choose Push or Pull
AppsFlyer's Push API postback pointed at Signals for real-time delivery, or a scheduled Pull API raw-data or aggregate report where Push is not yet configured.
-
Map af_ fields
AppsFlyer's af_events, af_status, and attribution fields mapped to each destination's app-conversion schema for Meta, Snap, and TikTok.
-
Filter and reconcile
Protect360-flagged installs dropped, identifiers hashed, and the event deduped against SDK traffic on AppsFlyer's event ID before anything leaves.
-
Deliver with match feedback
Server-side delivery to Meta, Snap, and TikTok, with per-destination match results visible in the live debugger.
AppsFlyer questions, answered.
Should we connect Signals to AppsFlyer's Push API or its Pull API?
Push, for most setups. AppsFlyer's Push API (its server-to-server postback) forwards each install and in-app event as it fires, which is what Signals needs to deliver an app conversion while the click and campaign data are still fresh. The Pull API stays useful for aggregate and raw-data reports, but it is a scheduled export, not a live event feed, so it is not the path Signals reads from for conversions.
Does Signals forward installs that AppsFlyer's Protect360 has flagged as fraud?
No. A Protect360-flagged install is fraud, not a customer, and forwarding it as a conversion would train an ad platform's algorithm on bad data. Signals reads AppsFlyer's fraud verdict on each postback and drops anything Protect360 has already rejected before mapping or hashing, so only the installs AppsFlyer itself trusts reach Meta, Snap, or TikTok.
How are SKAdNetwork installs handled compared to identifier-based ones?
SKAdNetwork installs carry a conversion value instead of a device identifier, and AppsFlyer decodes that value from its own mapping before the postback reaches Signals. Signals forwards the decoded event to each destination's app API as a privacy-safe install, alongside any GAID-backed Android installs and hashed-identifier events that carry more detail.
Do our existing AppsFlyer integrations to ad networks need to be removed?
Only a postback URL needs adding. AppsFlyer's existing partner postback setup for an ad network can stay active, and Signals adds a parallel, hashed server-side feed rather than replacing it. Dedupe runs on AppsFlyer's own event ID, so a network already receiving that install or purchase through its native AppsFlyer integration will not count it twice.
NEXT STEP
See your AppsFlyer data working in every ad platform.
Ready to enable a use case, or still mapping what AppsFlyer data could do? Our team helps you find the right place to start.
