Ellipse Gradient for Header

AppsFlyer Integration Guide

Integrate AppsFlyer attribution and marketing data with enterprise systems through REST APIs, Push API callbacks, reporting exports, and Data Locker files.

AppsFlyer integration options at a glance

AppsFlyer provides REST APIs for Pull API reporting, raw data, Master API administration, OneLink management, Audiences, and selected server-to-server workflows. Its Push API supports callback-style delivery for selected attribution and event data, while Data Locker and other reporting exports support high-volume and historical processing. Authentication varies by product and may use API tokens, admin credentials, developer keys, app identifiers, and account permissions. Martini can consume the APIs, receive supported callbacks through a REST API, process exported files, maintain report watermarks, transform data, and write normalized results to databases, warehouses, or business applications.

Integration pointSupported by AppsFlyer?Common use casesHow Martini supports it
REST APIsYesAppsFlyer provides REST APIs for Pull API reporting, raw data, Master API administration, OneLink management, Audiences, and selected server-to-server event or revenue workflows.Martini can consume the APIs in workflows, authenticate with configured secrets, paginate or partition requests, transform responses, and expose normalized APIs to downstream systems.
Webhooks / outbound callbacksLimitedPush API-style callbacks deliver selected attribution and event data in real time or near real time. Coverage depends on the configured AppsFlyer product and event type.Martini can expose a REST API to receive callbacks, validate requests, deduplicate events, route them to workflows, and return idempotent responses.
Bulk / async / batch APIsYesData Locker, raw-data reports, Pull API reports, aggregated reports, and some asynchronous reporting products support high-volume and scheduled data processing.Martini can orchestrate report requests, process partitions or report identifiers, maintain watermarks, load staging data, and reconcile batch results.
File / attachment exportsLimitedData Locker exports AppsFlyer reporting and raw-data files to configured cloud storage or transfer destinations. This is data export rather than a general-purpose attachment API.Martini can retrieve or consume supported files, parse JSON, CSV, or other confirmed formats, validate schemas, and write normalized records to target systems.
AuthenticationYesAppsFlyer uses API tokens, admin credentials, developer keys, app identifiers, and account or product permissions depending on the API family.Martini can store credentials in secrets, apply API authentication to requests, restrict callback endpoints, and separate credentials by environment and application.
Scheduled synchronizationYesScheduled extraction is appropriate for Pull API reports, reconciliation, historical backfills, campaign reporting, and Data Locker processing.Martini scheduler-triggered workflows can use date windows, report partitions, persistent watermarks, retry policies, and configurable lookback periods.
SDKs and server-to-server APIsYesAppsFlyer provides mobile SDKs and server-to-server capabilities for selected application events, conversions, and revenue workflows.Martini generally interacts with the resulting APIs, callbacks, or exported data rather than embedding a mobile SDK, and can orchestrate server-to-server exchanges.
GraphQL APIsNot confirmedNo official AppsFlyer GraphQL API documentation was confirmed in the supplied research.Martini can consume GraphQL APIs generally, but an AppsFlyer GraphQL integration should not be assumed without provider confirmation.
SOAP APIsNot confirmedNo official AppsFlyer SOAP API documentation was confirmed in the supplied research.Martini supports SOAP integrations generally, but AppsFlyer integration should be designed around confirmed REST, callback, and export mechanisms.

How AppsFlyer exposes data and business events

AppsFlyer REST APIs

AppsFlyer REST APIs cover Pull API reporting, raw-data and aggregated reports, Master API administration, OneLink management, Audiences, and selected server-to-server workflows. Endpoint availability and permissions depend on the AppsFlyer product and account configuration.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with an AppsFlyer token, admin credential, or developer key, calls the appropriate API for an app and date range, handles pagination or asynchronous reports, transforms the response, and writes it to a target application, database, or file.

Implementation sequence

Load the AppsFlyer credential and app identifier from secrets
Select the report, API product, application, and date window
Call the AppsFlyer REST API
Retrieve all pages or asynchronous report results
Map attribution data to the canonical model
Apply validation, enrichment, and business rulesкиг

AppsFlyer Push API callbacks

AppsFlyer Push API-style notifications provide selected attribution and event data through callback delivery. Coverage is product-specific and does not represent a universal webhook stream for every AppsFlyer object.

Martini implementation pattern

Martini implementation pattern: a Martini REST API receives the callback, validates authentication and payload structure, derives a deterministic event key, persists processing status, and routes the normalized event to Salesforce, a warehouse, or another customer-data system. Scheduled reconciliation supplements callbacks when attribution may be corrected or enriched later.

Implementation sequence

Receive the AppsFlyer callback at a protected Martini REST API
Validate the request and required AppsFlyer fields
Create an idempotency key from application and event dimensions
Persist the event and processing status
Transform and route the event to downstream systems
Return an idempotent response and monitor failures

AppsFlyer Data Locker exports

Data Locker and related reporting exports support high-volume, scheduled, and historical processing through files delivered to configured storage or transfer destinations. File structure, retention, partitioning, and availability depend on the AppsFlyer configuration and subscription.

Martini implementation pattern

Martini implementation pattern: a scheduled workflow discovers or retrieves available partitions, validates file completeness and schema, processes raw or aggregated data in batches, loads staging and curated targets, and records the source partition and watermark for replay-safe processing.

Implementation sequence

Identify the available AppsFlyer export partition or report
Retrieve or consume the configured data file
Validate file availability, schema, and partition boundaries
Parse and map the export into staging structures
Load normalized warehouse or database tables
Record the partition, watermark, and reconciliation result

Common AppsFlyer integration patterns

Pattern 1: Synchronize AppsFlyer attribution to Salesforce

When to use this pattern

Use this pattern when sales or customer-success teams need mobile attribution, install, campaign, and in-app event context in Salesforce. Scheduled reports are appropriate for complete or corrected data, while selected callbacks can reduce latency.

Integration direction
AppsFlyer
Martini
Salesforce
Example Mapping
AppsFlyer FieldCanonical FieldTarget Field
app_idapplicationIdAppFlyer_Application_Id__c
media_sourceattributionSourceLeadSource
campaigncampaignNameCampaign_Name__c
event_nameconversionEventEvent_Type__c
Martini implementation pattern

A scheduler-triggered Martini workflow retrieves AppsFlyer reports for a configurable lookback period, maps attribution dimensions to Salesforce Leads, Contacts, Campaign Members, or custom objects, applies campaign normalization and eligibility rules, and uses deterministic keys to prevent duplicates. Failed Salesforce writes are retried with backoff and retained for operational review.

Martini capabilities used
  • workflows
  • API consumption
  • scheduling
  • data mapping
  • business rules
  • error handling

Pattern 2: Stream AppsFlyer events to a data warehouse

When to use this pattern

Use this pattern when analytics teams require low-latency selected events together with complete historical and corrected data. Push callbacks provide responsiveness, while Data Locker or reporting APIs provide reconciliation and backfill.

Integration direction
AppsFlyer
Martini
Snowflake
Example Mapping
AppsFlyer FieldCanonical FieldTarget Field
event_timeoccurredAtEVENT_OCCURRED_AT
customer_user_idcustomerIdCUSTOMER_ID
event_nameeventTypeEVENT_NAME
media_sourceattributionSourceMEDIA_SOURCE
Martini implementation pattern

Martini receives supported Push API callbacks through a protected REST API, validates and deduplicates them, then loads normalized staging tables. A separate scheduled workflow reprocesses Data Locker partitions or report windows, corrects attribution changes, and merges data using source identifiers and event dimensions.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • data mapping
  • SQL database access
  • idempotency and error handling

Pattern 3: Publish AppsFlyer campaign reporting for BI

When to use this pattern

Use this pattern when marketing and finance teams need consistent campaign, media-source, install, and revenue metrics in Tableau or another reporting application. Batch reporting is preferable to event-by-event API calls for high-volume analytical workloads.

Integration direction
AppsFlyer
Martini
Google BigQuery
Tableau
Example Mapping
AppsFlyer FieldCanonical FieldTarget Field
campaigncampaignNamecampaign_name
media_sourcemediaSourcemedia_source
installsinstallCountinstall_count
ad_revenueadRevenuead_revenue
Martini implementation pattern

A scheduled Martini workflow retrieves aggregated reports or processes Data Locker files by date and application, applies campaign naming normalization, currency and time-zone rules, and attribution-window classification, then loads a reporting store consumed by Tableau. Watermarks, partition checks, and replay-safe merges support reliable refreshes.

Martini capabilities used
  • scheduling
  • batch processing
  • file processing
  • data transformation
  • SQL database access
  • monitoring and error handling

Pattern 4: Govern AppsFlyer OneLink administration

When to use this pattern

Use this pattern when marketing operations need controlled creation, update, or retrieval of OneLinks based on approved campaign metadata. Availability depends on AppsFlyer API access and account permissions.

Integration direction
Marketing operations system
Martini
AppsFlyer
Example Mapping
AppsFlyer FieldCanonical FieldTarget Field
campaign_namecampaignNameOneLink campaign parameter
deep_link_urldestinationUrlOneLink destination
channeltrafficChannelOneLink media-source parameter
requester_idrequestedByMartini audit record
Martini implementation pattern

Martini exposes a controlled internal API that validates campaign metadata, applies naming and authorization rules, invokes documented AppsFlyer OneLink operations, and records the request and response for audit. Transient API failures are retried, while permission or validation failures are returned without repeating the operation.

Martini capabilities used
  • API exposure
  • API consumption
  • validation
  • business rules
  • data mapping
  • audit and error handling

Applications commonly integrated with AppsFlyer

AppsFlyer data is commonly connected to advertising, sales, data-warehouse, analytics, customer-engagement, and customer-data products. Martini can coordinate these flows through APIs, callbacks, scheduled workflows, and exported files while preserving source data and applying consistent business rules.

Application Scenario Direction Martini Pattern
Salesforce Send attribution, install, campaign, and in-app event data to sales and customer-success teams, or use Salesforce data to support campaign operations. AppsFlyer → Martini → Salesforce A scheduled Martini workflow retrieves AppsFlyer reports, maps Apps, Installs, Campaigns, Media sources, and In-app events to Salesforce Leads, Contacts, Campaign Members, or custom objects, then applies deterministic keys and retry handling.
Google Ads Reconcile mobile conversions and campaign performance between AppsFlyer attribution data and Google advertising workflows. AppsFlyer → Martini → Google Ads Martini retrieves AppsFlyer attribution and campaign data, normalizes campaign dimensions and conversion timestamps, and exchanges approved data with Google Ads APIs according to the enabled account and product configuration.
Meta Ads Coordinate mobile attribution and conversion data for campaign measurement and optimization. AppsFlyer → Martini → Meta Ads A Martini workflow consumes AppsFlyer reports or supported callbacks, validates attribution fields, applies campaign and event rules, and routes the resulting data to Meta Ads through its available APIs or configured integration path.
Snowflake Centralize raw and aggregated AppsFlyer data for enterprise analytics, reporting, and model development. AppsFlyer → Martini → Snowflake Martini processes Data Locker or reporting exports, preserves raw files where required, maps them to versioned warehouse tables, records partitions and watermarks, and retries failed loads without duplicating data.
Google BigQuery Store high-volume AppsFlyer raw-data and reporting exports for SQL analysis and downstream analytics. AppsFlyer → Martini → Google BigQuery A scheduled workflow retrieves or consumes AppsFlyer exports, validates file partitions and schemas, transforms timestamps and attribution dimensions, and loads BigQuery staging and curated tables with reconciliation status.
Tableau Visualize AppsFlyer campaign, attribution, install, and revenue metrics for marketing and executive reporting. AppsFlyer → Martini → Tableau Martini normally loads normalized AppsFlyer data into a reporting database or warehouse used by Tableau, applying campaign naming rules, currency conversion, attribution-window classification, and incremental refresh controls.
Braze Use attribution and in-app event data to support mobile engagement, audience segmentation, and lifecycle campaigns. AppsFlyer → Martini → Braze Martini receives selected AppsFlyer callbacks or retrieves event reports, maps user and campaign context to Braze-compatible payloads, filters eligible events, and handles duplicate delivery and downstream API failures.
Segment Combine AppsFlyer attribution with product and customer events in a broader customer-data pipeline. AppsFlyer → Martini → Segment A Martini workflow normalizes AppsFlyer Installs and In-app events, enriches them with internal identifiers where available, and sends approved events or warehouse data to the configured Segment ingestion path.

How to build a AppsFlyer integration in Martini

Objective

Establish AppsFlyer access using the credential type required by the selected API product and application.

Instructions in Martini

  • Identify the AppsFlyer API family, app identifier, account permissions, and required token, admin credential, or developer key.
  • Store credentials in Martini secrets and configure separate values for each environment.
  • Define callback authentication and network controls if AppsFlyer Push API delivery will be received.

Objective

Select an event-driven, scheduled, or file-based trigger that matches the latency and completeness requirements.

Instructions in Martini

  • Use a protected Martini REST API for supported Push API callbacks.
  • Use a scheduler for Pull API reports, reconciliation, OneLink administration, or Data Locker processing.
  • Define a lookback period because attribution and event data can be corrected after first receipt.

Objective

Collect complete AppsFlyer API responses, callback payloads, or export partitions before transformation.

Instructions in Martini

  • Call the relevant REST API with the correct app, report, and date parameters.
  • Handle pagination, row limits, asynchronous report identifiers, and partition availability.
  • Persist cursors, report identifiers, source partitions, and date watermarks in a durable store.

Objective

Coordinate validation, enrichment, routing, persistence, and downstream calls in a maintainable Martini workflow.

Instructions in Martini

  • Separate low-latency callback handling from batch reconciliation where both are required.
  • Retain source payloads or files when auditability and replay are important.
  • Route records by object, event type, application, target system, or business outcome.

Objective

Normalize AppsFlyer-specific attribution and event structures into stable internal and target-system models.

Instructions in Martini

  • Map Apps, Installs, In-app events, Media sources, Campaigns, OneLinks, and revenue fields explicitly.
  • Normalize timestamps, time zones, campaign names, currencies, identifiers, and optional privacy-limited fields.
  • Version internal mappings so additive source schema changes can be introduced safely.

Objective

Apply business, privacy, eligibility, and idempotency rules before writing to target systems.

Instructions in Martini

  • Build deterministic keys from application and event dimensions rather than callback arrival time alone.
  • Filter or route data according to consent, identifier availability, campaign eligibility, and target requirements.
  • Validate required fields and distinguish retryable transport failures from permanent data or permission errors.

Common AppsFlyer data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AppsIdentify mobile applications configured in AppsFlyer by app ID, bundle ID, or package name.Salesforce, Snowflake, Google BigQuery, reporting databasesMartini uses app identifiers to parameterize API requests, validate incoming events, partition exports, and map application context into canonical models.
InstallsRepresent installation and attribution data, including media source, campaign, geographic, device, and attribution dimensions.Salesforce, Snowflake, Google BigQuery, TableauMartini retrieves Installs through reports or receives selected callback data, normalizes attribution fields, preserves event and ingestion timestamps, and applies deduplication.
In-app eventsCapture post-install actions such as registration, purchase, level completion, or subscription activity.Salesforce, Braze, Segment, data warehousesMartini validates event names and identifiers, maps event properties to target schemas, routes eligible events, and handles retries and duplicate callbacks.
Media sourcesDescribe advertising networks, partners, owned media, and other traffic sources associated with attribution.Google Ads, Meta Ads, Snowflake, TableauMartini standardizes source names, applies campaign attribution rules, and loads media-source dimensions into reporting or activation models.
CampaignsProvide campaign-level attribution dimensions, often with ad set and ad information.Salesforce, Google Ads, Meta Ads, TableauMartini maps campaign hierarchy and naming conventions, converts dates or currencies where needed, and supports incremental reconciliation.
OneLinksManage deep-link and attribution link configurations used to route users and measure campaigns.Marketing operations platforms, internal campaign APIs, AppsFlyerMartini can call documented OneLink API operations, validate metadata, enforce naming rules, and expose a controlled internal API.

Authentication and security considerations

Credential types

AppsFlyer authentication varies by API product. Pull API requests generally use API tokens, while other APIs and server-to-server workflows may use admin credentials, API tokens, developer keys, app identifiers, and account or product permissions.

Protecting credentials

Store AppsFlyer tokens, admin keys, and developer keys in Martini secrets rather than workflow source or request payloads. Separate credentials by environment and restrict access according to the integration's operational role.

Protecting callbacks

Receive Push API callbacks through a protected Martini REST API. Apply authentication, network controls, request validation, and idempotency checks, and configure AppsFlyer-specific callback signing where supported by the selected product.

Privacy controls

Mobile attribution data may contain device, advertising, user, and campaign identifiers. Minimize logging, apply retention controls, and design for missing identifiers or reduced attribution precision caused by consent, ATT, SKAdNetwork, and other mobile privacy restrictions.

Operational considerations for AppsFlyer integrations

Quotas and pagination

AppsFlyer quotas and rate limits vary by API product, endpoint, account, and subscription. Implement throttling, backoff for HTTP 429 responses, pagination, row-limit handling, and partitioned date windows.

Watermarks and reconciliation

Persist cursors, report identifiers, Data Locker partitions, and date-range watermarks. Reprocess a configurable lookback period because attribution and event data can be corrected or enriched after initial delivery.

Idempotency

Push callbacks may be retried or delivered more than once. Use deterministic keys based on AppsFlyer identifiers and relevant application, event, timestamp, device, user, and attribution dimensions.

Schema and time zones

Report columns and nested structures can vary by report type. Preserve source data where appropriate, validate required fields, version mappings, and define an explicit reporting time zone using half-open incremental intervals.

Testing and monitoring

Test API permissions, callback authentication, pagination, delayed attribution, duplicate delivery, empty reports, file partitions, and downstream failures. Monitor workflow logs, processing status, retry queues, and reconciliation results.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate multiple AppsFlyer mechanisms

AppsFlyer integrations commonly combine REST APIs, selected callbacks, scheduled reporting, and Data Locker exports. Martini coordinates these paths in workflows rather than forcing each mechanism into a separate script.

Keep mappings and rules maintainable

Martini provides structured mapping, transformation, validation, routing, and reusable integration logic for Apps, Installs, In-app events, Campaigns, Media sources, and OneLinks.

Design for reliable operations

Persistent watermarks, idempotency, retries, reconciliation, logging, and controlled error handling help address rate limits, delayed attribution, duplicate callbacks, schema changes, and high data volumes.

Expose controlled APIs

Martini can expose normalized APIs for downstream applications or controlled OneLink administration while keeping AppsFlyer credentials, provider-specific behavior, and business rules behind a governed integration boundary.

Frequently asked questions

How can AppsFlyer be integrated with enterprise systems?

AppsFlyer can be integrated through its REST APIs, selected Push API callbacks, reporting APIs, Data Locker exports, and server-to-server capabilities. REST APIs suit targeted reporting, administration, OneLink, audience, and event workflows; Data Locker and batch reporting suit high-volume or historical data; callbacks support selected near-real-time attribution and event delivery.

Can Martini integrate with AppsFlyer?

Yes. Martini can consume AppsFlyer REST APIs, expose a REST API for supported Push API callbacks, process Data Locker or reporting files, schedule reconciliation workflows, map AppsFlyer data, and write results to databases, warehouses, or enterprise applications. No native Martini AppsFlyer connector is documented in the supplied materials.

Do I need a connector to integrate AppsFlyer with Martini?

No dedicated AppsFlyer connector is required. Martini can use AppsFlyer's confirmed native integration mechanisms, including REST APIs, selected Push API callbacks, authentication credentials, reporting exports, and Data Locker files.

Is there any extra Lonti cost to integrate AppsFlyer with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate AppsFlyer. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from AppsFlyer, cloud infrastructure, storage, or other third-party systems depending on subscription, usage, and deployment model.

Which AppsFlyer integration method should an enterprise use?

Use REST APIs for targeted operational queries, Pull API reports, Master API administration, OneLink operations, and selected server-to-server workflows. Use Push API callbacks for supported low-latency events, and Data Locker or batch reporting for high-volume historical and analytical pipelines. Many implementations combine these methods.

Does AppsFlyer provide events or webhooks for Martini?

AppsFlyer supports Push API-style callbacks for selected installs, in-app events, organic installs, uninstall or reinstall-related data, and other configured attribution or conversion data. Coverage is product-specific rather than universal, so callback processing should be supplemented with scheduled reconciliation when completeness or correction handling is required.

How does Martini synchronize and transform AppsFlyer data?

Martini can use date ranges, Data Locker partitions, event timestamps, report identifiers, and persistent watermarks to implement incremental synchronization. Workflows map AppsFlyer objects and attribution dimensions into versioned internal models, apply campaign, time-zone, currency, and privacy rules, and load target systems with replay-safe keys.

How are AppsFlyer errors, retries, and duplicates handled?

Martini workflows can classify retryable rate-limit and transport failures, retry with backoff, and retain failed items for investigation. Callback and batch flows should use deterministic event or partition keys, persistent processing status, schema validation, and reconciliation lookbacks to handle duplicate delivery and later attribution corrections.

Related Martini documentation

APIs

Callbacks

Workflows

Data

Security

Connect AppsFlyer to your enterprise systems

Use Martini to build governed AppsFlyer integrations across APIs, Push API callbacks, reporting workflows, and Data Locker exports.

EXPLORE MARTINI
BOOK A DEMO