Send AppsFlyer Data to Angler via Push API

Overview

AppsFlyer's Push API streams raw attribution event data to a server-side endpoint in real time. You can use it to send mobile install and in-app purchase events directly into Angler, so Angler has a complete, attributed view of your mobile conversions alongside your web events.

This guide covers how to configure the AppsFlyer Push API to send events to your Angler workspace.

Prerequisites

Before you begin:

You must be the AppsFlyer account owner — only account owners can create or modify Push API endpoints.
You'll need your Angler Push API webhook URL, which includes your workspace ID and API token. Your Angler account manager will provide this, or you can generate a token yourself — see Create API Access Tokens.
At least one in-app event must have been recorded in AppsFlyer before you can select it as a Push API event type. If needed, fire a test event from a test device first.

Step 1: Get your Angler webhook URL

Your Angler webhook URL for AppsFlyer Push API events follows this format:

https://webhooks.getangler.ai/v1/appsflyer/data/<WORKSPACE_ID>?token=<YOUR_API_TOKEN>

For example:

https://webhooks.getangler.ai/v1/appsflyer/data/ws-brand-abc123?token=<YOUR_API_TOKEN>

Your workspace ID and token are available in your Angler dashboard. See Create API Access Tokens for instructions on generating a token with CLIENT_EVENTS scope.

Step 2: Configure the Push API endpoint in AppsFlyer

In your AppsFlyer dashboard, go to Reports → API Access.
Scroll down to the Push API section.
Click Add Endpoint.
Set the HTTP method to POST.
Paste your Angler webhook URL (including the ?token=... query parameter) into the Endpoint URL field.
Click Save.

Step 3: Select event types

Under Event Types, select All to forward every event type to Angler. This ensures Angler has complete visibility into your mobile user journey — including installs, re-engagements, and all in-app events — which improves attribution accuracy and model performance.

Note: The in-app events list only shows event types that have already been recorded in AppsFlyer. If an event is missing, fire it from a test device first and then return to this step.

Step 4: Select message fields

The following fields are always included in every Push API message regardless of your selection:

app_id
event_name
event_time
idfa (iOS) or advertising_id (Android)

We recommend also enabling these optional fields so Angler can correctly process, attribute, and forward events to downstream ad platforms:

Field	Why it's needed
`customer_user_id`	Maps the event to a known user in Angler
`event_value`	Contains revenue (`af_revenue`), currency, and order details
`appsflyer_id`	AppsFlyer's unique device identifier
`idfv`	iOS Identifier for Vendor — improves identity resolution and reinstall attribution
`platform`	`ios` or `android` — needed for cross-platform attribution
`device_type`	Device model (e.g. `iPhone 14`) — required when forwarding events to Meta as app events
`device_category`	`phone` or `tablet` — used for Meta app event delivery
`os_version`	Operating system version — required for Meta app events
`app_version`	App version at time of event — used for Meta app events and debugging
`media_source`	Paid channel attribution (e.g. `facebook`, `googleadwords_int`)
`campaign`	Campaign name for channel-level reporting
`af_c_id`	Campaign ID — stable identifier to complement `campaign` name
`af_adset` / `af_adset_id`	Ad set name and ID — sub-campaign granularity
`af_ad` / `af_ad_id`	Creative name and ID — creative-level attribution
`attributed_touch_type`	Click-through vs. view-through attribution context
`attributed_touch_time`	Timestamp of the last attributed touch
`install_time`	Original install timestamp — used for cohort analysis and LTV modeling
`is_retargeting`	Flags retargeting events — useful for deduplication
`is_primary_attribution`	Identifies the primary attribution for retargeting duplicate events
`country_code`	Geographic segmentation
`city`	City-level geo data
`postal_code`	Postal code — granular geo context
`language`	Device language setting
`wifi`	Whether the device was on WiFi at time of event
`ip`	Used for identity resolution
`user_agent`	Device/browser context

💡
AppsFlyer omits null or empty fields from the payload entirely — unselected fields simply won't be present.

Step 5: Test the endpoint

Click Send Test in the Push API configuration panel.
AppsFlyer will POST a test message to your Angler endpoint. It expects an HTTP 200 response within 2 seconds — if it doesn't receive one, the test is marked as failed.
If the test fails, verify that your webhook URL and token are correctly formatted and that the token has CLIENT_EVENTS scope.

Step 6: Save and verify

Click Save. The Push API is now live and will begin forwarding events to Angler in real time.

To verify data is arriving, check the Events Monitor in your Angler workspace and confirm events are appearing as expected.

Notes and limitations

One event per request. AppsFlyer sends each event as a separate POST — there is no batching.
SKAdNetwork (SKAN). The same Angler webhook URL supports both standard AppsFlyer attribution and SKAN attribution events. When setting up a SKAN endpoint in AppsFlyer, use the same URL.
Retargeting duplicates. If both UA and retargeting campaigns are active, purchase events during a re-engagement window may be sent twice — once attributed to the UA source and once to the retargeting source. Use is_primary_attribution to filter to the primary attribution row downstream.

Troubleshooting

Symptom	Likely cause	Fix
Test message fails	Token missing, malformed, or wrong scope	Verify the full URL and that the token has `CLIENT_EVENTS` scope
Events arrive but have no revenue	`event_value` not selected in message fields	Enable `event_value` in the Push API field selector
Event missing from event type list	Event not yet recorded in AF	Fire it from a test device, then refresh
Delivery timeouts	Endpoint not responding within 2s	Contact Angler support to check webhook health