AppsFlyer Postback Integration for Affiliate Tracking: The Setup Guide

AppsFlyer is the MMP you will meet most often on app offers, and its integration model is well defined: your network becomes an integrated partner, your click ID rides the attribution link, and AppsFlyer returns it in server-side postbacks for every install and in-app event it attributes to you. This guide walks the setup end to end — including the signature verification and event filtering steps that casual integrations skip and later regret. If the tracker–MMP architecture is new to you, start with the mobile attribution guide.

Prerequisites

• The advertiser has your network enabled as an integrated partner in their AppsFlyer dashboard
• The app's App ID (iOS: id123456789 — Android: com.company.app)
• Optionally, a Dev Key (AppsFlyer → Configuration → API Access) for pulling raw reports
• Your tracker's click ID macro and postback endpoint

Step 1 — Build the Attribution Link

The attribution link is an app.appsflyer.com URL carrying your partner ID (pid) plus the parameters that let AppsFlyer hand attribution context back to you. A production-shaped example:

https://app.appsflyer.com/com.company.app
   ?pid=yournetwork_int
   &af_siteid={affiliate_id}      // your publisher ID
   &af_sub_siteid={sub_aff1}      // your sub-affiliate slot
   &click_id={click_id}           // YOUR click ID — the critical one
   &af_c_id={campaign_id}
   &af_c={campaign_name}
   &gaid={gaid}&idfa={idfa}       // device IDs where consented

Two rules keep this link healthy. First, the click ID must be generated per click and passed unmodified — it is the only key that reconnects the install to your click record. Second, populate af_siteid with the publisher ID on every click; it is how the advertiser sees source-level quality inside AppsFlyer, and advertisers cut networks that show up as one anonymous blob.

Step 2 — The Macro Mapping

The naming translation between AppsFlyer and your affiliate hierarchy is where most broken integrations break. The canonical mapping:

Affclix generates this mapping automatically per campaign — the integration screen emits the attribution link and both postback URLs with macros pre-filled, so the failure mode above simply does not occur.

Step 3 — Configure Install & Event Postbacks

In the advertiser's AppsFlyer integration settings for your partner ID, two destinations are configured. The install postback fires once per attributed install; the in-app event postback fires per mapped event and carries the event name and revenue:

// Install
https://track.yourdomain.com/postback
   ?click_id={clickid}&iosidfa={idfa}&gaid={gaid}

// In-app event (CPA / RevShare)
https://track.yourdomain.com/postback
   ?click_id={clickid}
   &event={partner_event_identifier}
   &payout={revenue_amount}

Have the advertiser map the in-app events you pay on (registration, purchase, deposit) to partner event identifiers, and agree on the identifier names up front — renaming events after launch silently breaks CPA rules. Configure event postbacks even for pure CPI deals; post-install event flow is your best install-farm detector.

Step 4 — Verify Postback Signatures

AppsFlyer can sign postbacks with a shared secret: the signature header carries an HMAC-SHA256 of the raw request body. Your tracker recomputes the digest with the shared secret and rejects mismatches. Without this, anyone who discovers your postback URL format can fabricate installs with a shell script. Affclix verifies signatures automatically when a postback secret is configured on the integration, using a constant-time comparison, and logs a warning when an integration runs unsigned so it is visible at audit time.

Step 5 — Filter Organic, Fraud, and Duplicates

Three payload fields decide whether a postback should ever become a commission. af_status=Organic marks unattributed installs — forward-friendly advertisers sometimes send them for completeness, and they must not convert. A populated fraud_reason field means AppsFlyer's Protect360 flagged the event — hard-block it. And is_retargeting=true marks re-engagement, which needs its own payout rules or none. On top of field filtering, deduplicate by click ID + event: AppsFlyer retries undelivered postbacks, and a non-idempotent endpoint turns every retry into a paid conversion.

Troubleshooting the Usual Failures

• Postbacks arrive without a click ID — the attribution link is missing the click_id parameter, or the advertiser's template stripped it. Fix the link; installs already attributed are recoverable via raw-report pull with the Dev Key.
• Installs show in AppsFlyer but no postbacks arrive — the postback destination for your partner ID is unconfigured or filtered to specific media sources. Confirm the integration tab settings with the advertiser.
• Numbers diverge over time — usually attribution-window mismatch or organic/retargeting leakage. Align windows, then reconcile against the raw installs report (pulled with the Dev Key) rather than dashboard aggregates.
• Event postbacks missing revenue — the advertiser mapped the event but not the revenue field; payout={revenue_amount} only populates when revenue forwarding is enabled per event.

On Affclix, the AppsFlyer integration screen generates the attribution link and both postback URLs pre-mapped, verifies signatures, filters organic and Protect360-flagged events, and pulls raw reports for reconciliation — the whole pipeline in this guide, without hand-assembly.

Frequently Asked Questions

How do I send AppsFlyer conversions to my affiliate tracker?

Configure your network as an integrated partner in AppsFlyer, put the tracker's click ID macro on the attribution link, and set the tracker's postback URL as the install and in-app event postback destination. AppsFlyer then calls that URL server-side with the click ID each time it attributes a conversion to your link.

What is an AppsFlyer Dev Key and where do I find it?

The Dev Key is the API credential for an AppsFlyer app account, generated under Configuration → API Access in the AppsFlyer dashboard. Trackers use it to pull raw install reports for reconciliation alongside the real-time postback stream.

How are AppsFlyer postbacks verified?

With a shared postback secret: AppsFlyer signs the raw postback body with HMAC-SHA256 and the tracker recomputes the signature and compares. Unsigned integrations work but accept the risk of spoofed postbacks — configure the secret in production.