Skip to main content

AppsFlyer Destination

Nexla's bi-directional connectors allow data to flow both to and from any location, making it simple to create a FlexFlow data flow that sends data to an AppsFlyer location.
apps_flyer_api.png

AppsFlyer

Create an AppsFlyer Destination​

  1. Click the + icon on the Nexset that will be sent to the AppsFlyer destination, and select the Send to Destination option from the menu.

  2. Select the AppsFlyer connector from the list of available destination connectors. Then, select the credential that will be used to connect to the AppsFlyer account, and click Next; or, create a new AppsFlyer credential for use in this flow.

  3. In Nexla, AppsFlyer destinations can be created using pre-built endpoint templates, which expedite destination setup for common AppsFlyer endpoints. Each template is designed specifically for the corresponding AppsFlyer endpoint, making destination configuration easy and efficient.
    • To configure this destination using a template, follow the instructions in Configure Using a Template.

    AppsFlyer destinations can also be configured manually, allowing you to send data to AppsFlyer endpoints not included in the pre-built templates or apply further customizations to exactly suit your needs.
    • To configure this destination manually, follow the instructions in Configure Manually.

Configure Using a Template​

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common AppsFlyer endpoints. Each template is designed specifically for the corresponding AppsFlyer endpoint, making destination setup easy and efficient.

  • To configure this destination using a template, select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

    Send Server-to-Server In-App Event

    This endpoint sends a mobile in-app event from your servers to AppsFlyer using the Server-to-Server (S2S) events API. Use it to report events that happen outside the app — for example, a subscription renewal on your web checkout, a back-office purchase, or a server-driven achievement — so AppsFlyer can attribute and aggregate them alongside SDK-reported events.

    • Optionally enter the AppsFlyer app identifier in the App Id field to override the upstream record's app ID. The default behavior is to read the value from each upstream record so that one destination can fan out events for multiple apps.
    • Each record in the upstream Nexset must include the standard S2S event fields. At a minimum: appsflyer_id (the device's AppsFlyer ID, captured by the SDK on first install), eventName (the event identifier, for example af_purchase), eventValue (the event payload, typically a JSON-encoded string), eventTime (event timestamp in yyyy-MM-dd HH:mm:ss.SSS format), and eventCurrency (ISO-4217 currency code) for revenue events.

    The S2S event payload is limited to 1KB and URL-reserved characters must be percent-encoded. For the complete field reference, see the AppsFlyer Server-to-server events API for mobile (S2S-mobile) documentation.

    Measure First App Opens (S2S)

    This endpoint records a first-app-open event with device, user, and session information so AppsFlyer can attribute the install to the correct media source. Use it to measure installs for app environments where the AppsFlyer SDK cannot run (for example, server-driven or kiosk apps).

    • Enter the app platform in the Platform field. This is required. Allowed values are ios and android.
    • Enter the AppsFlyer app identifier in the App ID field. This is required. Use the App Store ID prefixed with id for iOS, or the package name for Android.
    • Each record in the upstream Nexset must include the standard S2S first-open fields — device identifiers (idfa/idfv for iOS, advertising_id/android_id for Android), ip, user_agent, installed_at, and any additional attribution fields required by your AppsFlyer setup.

    First-open events represent installs and must be sent before any subsequent in-app events for the same device. Sending in-app events first will cause AppsFlyer to drop them as unattributed.

    Measure Sessions (S2S)

    This endpoint records a session event so AppsFlyer can measure retention, daily active users, and session-based KPIs. Use it for app environments without the AppsFlyer SDK, where sessions are detected server-side.

    • Enter the app platform in the Platform field. This is required. Allowed values are ios and android.
    • Enter the AppsFlyer app identifier in the App ID field. This is required.
    • Each record in the upstream Nexset must include the device identifier (appsflyer_id, plus idfa/idfv or advertising_id/android_id), ip, user_agent, and the session timestamp (eventTime).

    Session events must be sent after the corresponding first-open event for the same device. AppsFlyer rate-limits session events per device, so do not send sessions more often than the app's natural session frequency.

    Create OneLink Short Link

    This endpoint creates a new OneLink short link for a OneLink campaign, optionally with a custom TTL and brand domain. Use it to generate deep links at scale — for example, one short link per user, per ad creative, or per QR code printed on physical collateral.

    • Enter the OneLink campaign identifier in the OneLink ID field. This is required. The OneLink ID is the template-level identifier configured in the AppsFlyer OneLink Management dashboard.
    • Optionally, enter a custom short-link identifier in the Short Link ID field. When omitted, AppsFlyer generates a random short link ID.
    • Optionally, enter an expiration time (in seconds) for the short link in the TTL (seconds) field. When omitted, AppsFlyer uses the default TTL for the OneLink template.
    • Optionally, enter a custom branded domain in the Brand Domain field. The branded domain must be configured in AppsFlyer beforehand.
    • The full request body — including data (the deep-link parameters) and any optional fields like ad or af_channel — is sent as the JSON body of the call. Use the Nexla transform layer to shape upstream record attributes into the OneLink request schema.

    AppsFlyer recommends enabling the Response Webhook option in Configure Manually for this endpoint to capture the newly created short link URL into a Nexla webhook source for downstream use. For complete details on creating OneLink short links, see the AppsFlyer OneLink API reference.

    Create iOS Deep Linking Request

    This endpoint sends iOS Universal Link (deep linking) attribution requests with device identifiers, user tracking, and attribution information. Use it to forward iOS deep-link clicks captured by your own backend to AppsFlyer for attribution.

    • Enter the AppsFlyer app identifier in the App ID field. This is required. Use the App Store ID prefixed with id (for example, id123456789).
    • Each record in the upstream Nexset must include the iOS deep-link attribution payload — at minimum the device identifier (idfa or idfv), the click identifier or universal-link URL, and the click timestamp. Refer to the AppsFlyer Deep Linking API documentation for the complete schema.

    This endpoint targets the legacy iOS Universal Links attribution flow. For most modern integrations, prefer the SDK-based deep-link handling or the OneLink API.

Configure Manually​

AppsFlyer destinations can be manually configured to send data to any valid AppsFlyer API endpoint. Manual configuration provides maximum flexibility for endpoints not covered by pre-built templates — including the OneLink Update/Delete endpoints, Push API subscription updates, or custom S2S event variants.

Using manual configuration, you can also configure Nexla to automatically send the response received from the AppsFlyer API after each call to a new Nexla webhook data source. This is particularly useful for capturing the short link URL returned by Create OneLink Short Link, or the per-event success/failure response from the S2S events API.

API Method​

  1. To manually configure this destination, select the Advanced tab at the top of the configuration screen.

  2. Select the API method that will be used for calls to the AppsFlyer API from the Method pulldown menu. Common methods for AppsFlyer write endpoints include:

    • POST: For creating resources (for example, S2S events, OneLink short links, deep-link requests)
    • PUT: For updating resources (for example, updating an existing OneLink short link)
    • DELETE: For removing resources (for example, deleting a OneLink short link)

Data Format​

  1. Select the format in which the Nexset data will be sent to the AppsFlyer API from the Content Format pulldown menu. All AppsFlyer write endpoints expect application/json, so JSON is the appropriate choice for every AppsFlyer destination.

API Endpoint URL​

  1. Enter the URL of the AppsFlyer API endpoint to which you want to send the Nexset data in the URL field. AppsFlyer uses different base hosts depending on the API family:

    • S2S events (Send Server-to-Server In-App Event): https://hq1.appsflyer.com/inappevent/{'{app_id}'}
    • S2S first opens and sessions: https://api2.appsflyer.com/inappevent/{'{platform}'}/{'{app_id}'}
    • iOS Universal Link attribution: https://api.appsflyer.com/api/v1/uls/ios/{'{app_id}'}
    • OneLink short-link creation, retrieval, and update: https://onelink.appsflyer.com/shortlink-sdk/v2/{'{onelink_id}'}

    For update/upsert operations, include the ID of the object to be updated at the end of the URL — Nexla macros can substitute the ID from each upstream record.

Request Headers​

Optional

  • If Nexla should include any additional request headers in API calls to this destination, enter the headers & corresponding values as comma-separated pairs in the Request Headers field (for example, header1:value1,header2:value2).

    You do not need to include the Authorization header — Nexla automatically attaches the Authorization: Bearer <token> header based on the AppsFlyer credential selected for this destination, and Content-Type: application/json is added based on the selected Content Format.

Exclude Attributes from the Call​

Optional

  • If any record attributes in the Nexset should be omitted when sending data to this AppsFlyer destination, select the attributes from the Exclude Attributes pulldown menu. This is useful for stripping internal Nexla bookkeeping fields or upstream identifiers that AppsFlyer would reject as unknown.

  • Any number of attributes can be selected for exclusion, and all excluded attributes will be shown in the field. To remove an attribute from the list, click the X icon next to the attribute name.

Record Batching​

Optional

The AppsFlyer S2S events API and OneLink API process each request as a single resource — they do not support batched create/update calls. Record batching in Nexla is therefore best left disabled for AppsFlyer destinations to ensure each event maps to a single API call.

  1. To override the default and group records into a single batched payload anyway, check the box next to Would you like to batch your records together?.

  2. Enter the maximum number of records that should be batched together in a single API call in the Batch Size field. By default, this value is set to 100.

  3. Select the algorithm that will be used to group records into batches from the Grouping Algorithm pulldown menu. The sample request shown in the panel on the right will be updated to reflect the current batching settings.

Response Webhook​

Optional

Nexla can automatically send the response received from the AppsFlyer API after each call to a new Nexla webhook data source. This option allows you to keep track of the status of each API call, capture the newly created short link URL returned by Create OneLink Short Link, or branch downstream processing on per-event success or failure.

  • To enable this option, check the box next to Would you like to process the API response as a Nexla Webhook source?.

    Enabling the response webhook is particularly useful for Create OneLink Short Link (to capture the new short link URL and short link ID), and for S2S event destinations where downstream branching depends on per-event success.

Sample Request Payload​

Sample request payloads containing a portion of the Nexset data that will be sent to the AppsFlyer API endpoint based on the current settings are shown in the Sample Payload panel on the right. These samples can be referenced to ensure that the destination and request settings are correctly configured.

  • Click on a sample request payload to expand it and view the complete payload content.

  • Sample payloads are automatically updated with each setting change, making it easy to verify that changes achieve the desired effect.

Endpoint Testing (Manual Configuration)​

After all endpoint settings have been configured, Nexla can send a test payload to the AppsFlyer API to ensure that the destination is configured correctly.

  1. To send a test payload, select the Test button at the top of the Sample Payload panel, and click on a listed sample payload to expand it.

  2. If any modifications to the sample payload are needed, make the necessary changes directly within the sample window.

  3. Click the Send Test Data button at the top of a sample payload to send the test payload to the AppsFlyer API using the current settings.

Important

Test payloads sent to write endpoints (such as S2S in-app events, S2S first opens, S2S sessions, or Create OneLink Short Link) make real, billable changes in your AppsFlyer account — they affect attribution counts and may consume OneLink short-link quota. Use a sandbox or test app before sending test data against a production AppsFlyer account.

Save & Activate the Destination​

  • Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To begin sending data to AppsFlyer, open the destination resource menu, and select Activate.

    The Nexset data will not be sent to AppsFlyer until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.