Connect AppsFlyer to Claude: Manage Attribution & App Configurations

If your team needs to connect AppsFlyer to Claude to automate attribution reporting, manage SKAdNetwork (SKAN) configurations, or process OpenDSR compliance requests, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and AppsFlyer's specialized REST APIs. You can either build and maintain this API infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our sibling guide on connecting AppsFlyer to ChatGPT. If you are orchestrating broader automated pipelines, explore our architectural overview on connecting AppsFlyer to AI Agents.

Giving a Large Language Model (LLM) read and write access to a mobile attribution and marketing analytics platform like AppsFlyer is an engineering challenge. You have to handle API key lifecycles, map massive report schemas to MCP tool definitions, and deal with AppsFlyer's strict data access quotas. Every time AppsFlyer updates an endpoint - such as transitioning from SKAN V3 to V4 - you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for AppsFlyer, connect it natively to Claude Desktop, and execute complex marketing operations using natural language.

The Engineering Reality of the AppsFlyer API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specialized B2B APIs is painful. AppsFlyer is built to ingest billions of mobile events, run complex attribution logic, and enforce strict data privacy rules. Its API reflects that scale and complexity.

If you decide to build a custom AppsFlyer MCP server, here are the specific integration challenges you will face:

Reporting Asymmetry and Plan Constraints The AppsFlyer API treats raw data and aggregate data entirely differently. Aggregate endpoints (like Master Reports) require specific grouping arrays (pid, c, geo) and KPI selections, and they will outright return HTTP 416 or 404 errors if the account is on the free Zero plan. Raw data endpoints (like in-app events or blocked clicks) can return up to 1,000,000 rows per call and require specific account features like Protect360 to even be accessible. An LLM has no context on your billing plan. You must build tools with schemas that explicitly guide Claude away from requesting endpoints your account is not authorized to access.

OpenDSR Asynchrony Handling Data Subject Requests (DSR) for GDPR/CCPA compliance is not a standard CRUD operation. In AppsFlyer, OpenDSR is highly asynchronous. When you submit a batch of OpenDSR requests, AppsFlyer accepts the payload but takes several minutes to register the jobs internally. If your LLM immediately queries the status endpoint after submission, AppsFlyer will return a "Request not found" error. A custom MCP server must implement complex polling or strictly define tool descriptions that force the LLM to wait before verifying status.

SKAdNetwork (SKAN) Version Conflicts Apple's SKAdNetwork introduces deep complexity for iOS apps. AppsFlyer exposes separate base paths for SKAN V3 (/v2/) and SKAN V4 (/v3/). If an LLM calls the SKAN V4 endpoint but the underlying postbacks belong to V3 campaigns, the V4-specific fields silently return null. Furthermore, passing an Android app ID to a SKAN endpoint triggers an immediate HTTP 400. You have to write abstraction logic to prevent Claude from mixing platforms and attribution framework versions.

Generating the AppsFlyer MCP Server

Truto eliminates the need to build and host custom integration layers. When you connect an AppsFlyer account, Truto reads the integration's resource definitions and automatically generates an MCP server containing ready-to-use tools.

Truto handles the underlying API keys, formats the JSON-RPC 2.0 responses, and maps AppsFlyer's complex query parameters into standardized JSON Schema for Claude.

You can generate the AppsFlyer MCP server using either the Truto user interface or the API.

Method 1: Via the Truto UI

For teams who want a zero-code setup, you can generate the server directly from the dashboard:

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected AppsFlyer account.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., provide a name, restrict allowed methods to read only, or filter by specific tags).
5. Click Save and copy the generated MCP server URL (e.g., https://api.truto.one/mcp/a1b2c3...).

Method 2: Via the Truto API

For engineering teams building automated provisioning pipelines, you can generate the MCP server programmatically. Make a POST request to /integrated-account/:id/mcp.

curl -X POST https://api.truto.one/admin/integrated-accounts/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "AppsFlyer Analytics Agent",
    "config": {
      "methods": ["read", "custom"],
      "tags": ["reporting", "onelink"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

Truto returns a JSON payload containing the secure url.

{
  "id": "mcp_srv_9x8y7z",
  "name": "AppsFlyer Analytics Agent",
  "config": { "methods": ["read", "custom"], "tags": ["reporting", "onelink"] },
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f6..."
}

This URL is fully self-contained. It handles authentication and exposes the filtered AppsFlyer tools via the MCP protocol.

Connecting the MCP Server to Claude

Once you have your Truto MCP URL, you need to connect it to Claude. Depending on your environment, you can use the Claude UI or a manual configuration file.

Method 1: Via the Claude UI (Web/Desktop)

If your Claude plan supports custom remote connectors via the UI:

1. Open Claude and go to Settings -> Integrations -> Add MCP Server (or Settings -> Connectors -> Add custom connector depending on your exact version).
2. Name the integration (e.g., "AppsFlyer via Truto").
3. Paste the Truto MCP server URL.
4. Click Add.

Claude will immediately call the tools/list endpoint on the Truto server and populate its context with the available AppsFlyer operations.

Method 2: Via Manual Configuration File (Claude Desktop)

Claude Desktop natively expects MCP servers to communicate over local standard input/output (stdio). Because Truto is a remote, managed service, it uses Server-Sent Events (SSE) over HTTPS. You must use the official @modelcontextprotocol/server-sse wrapper to bridge the local stdio connection to Truto's remote SSE endpoint.

Open your claude_desktop_config.json file. On macOS, this is typically located at ~/Library/Application Support/Claude/claude_desktop_config.json. Add the following configuration:

{
  "mcpServers": {
    "appsflyer-truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/YOUR_GENERATED_TOKEN"
      ]
    }
  }
}

Restart Claude Desktop. The application will use npx to run the SSE client, which connects securely to Truto's remote AppsFlyer server.

High-Leverage AppsFlyer Hero Tools

The AppsFlyer integration exposes dozens of endpoints. By leveraging Truto, Claude dynamically generates specific JSON schemas for each operation. Below are 6 high-leverage hero tools that unlock powerful workflows for marketing ops and engineering teams.

list_all_apps_flyer_master_reports

This is the core analytics tool. It fetches the Master API report, providing aggregated KPIs for a specific app grouped by dimensions like media source, campaign, or geo. It requires specific from and to dates (yyyy-mm-dd format), grouping dimensions, and KPI metrics.

"Claude, pull the AppsFlyer Master Report for app ID 'id123456789' from 2026-10-01 to 2026-10-07. Group the data by media source (pid) and campaign (c), and return the total installs and revenue KPIs. Format the output as a Markdown table."

create_a_apps_flyer_onelink_link

OneLink is AppsFlyer's deep linking solution. This tool allows Claude to programmatically generate custom tracking links for specific campaigns, automatically embedding the necessary routing rules for iOS, Android, and Web fallbacks. It utilizes the OneLink API key configured in Truto.

"Generate a new AppsFlyer OneLink for our upcoming 'Winter Sale 2026' campaign. Set the media source to 'email', the campaign name to 'winter_sale', and set the deep link value to 'promo_code_page'. Provide me the final shortened URL."

create_a_apps_flyer_opendsr_request

Managing GDPR and CCPA data deletion requests manually is tedious. This tool initiates a Data Subject Request (OpenDSR) to access or delete user data. AppsFlyer requires specific identity types (like IDFA, GAID, or AppsFlyer ID) to execute the request.

"Submit an OpenDSR deletion request to AppsFlyer for the user with the AppsFlyer ID '12345678-1234-1234-1234-1234567890ab'. Verify that the request submitted successfully and give me the subject_request_id so we can track it."

create_a_apps_flyer_s_2_s_event

Server-to-Server (S2S) events allow you to log in-app actions from your backend instead of the mobile SDK. This tool requires the app ID, the user's AppsFlyer ID, an event name, and the event timestamp. It relies on the S2S developer key stored in the Truto connection.

"Send a server-to-server event to AppsFlyer for app 'com.example.app'. The event name is 'subscription_renewed', the value is $19.99, and the AppsFlyer ID for the user is 'abc-123-def'. Make sure to set the currency to USD."

update_a_apps_flyer_push_api_configuration_by_id

The Push API forwards real-time event postbacks to your internal infrastructure. This tool allows Claude to update the endpoint URL, adjust the HTTP method, or modify the selected fields (which must always include core identifiers like event_time and app_id).

"Update our AppsFlyer Push API configuration. Change the destination URL to 'https://data.ourcompany.com/webhooks/appsflyer' and ensure that the event types include both 'install' and 'in-app-event'. Leave the existing selected fields intact."

list_all_apps_flyer_raw_in_app_events

When aggregate data isn't enough, this tool pulls raw CSV rows of in-app events. Because raw data reports can return up to 1,000,000 rows per call, it requires precise datetime filters. This tool is strictly gated by the account's raw data access plan.

"Fetch the raw in-app events from AppsFlyer for yesterday between 14:00 and 15:00 UTC. We are looking for any anomalies in the 'purchase' event stream. Summarize the event counts by media source."

For a complete list of supported endpoints, schemas, and required parameters, consult the AppsFlyer integration page.

Workflows in Action

Providing an AI agent with isolated tools is just the first step. The true power of an MCP server emerges when Claude chains these tools together to orchestrate multi-step business logic. Here are practical examples of AppsFlyer workflows.

1. The Automated GDPR Compliance Pipeline

Persona: Data Privacy Officer / Backend Engineer

Processing Data Subject Requests (DSRs) involves submitting deletion jobs and verifying their completion. Because AppsFlyer OpenDSR requests are asynchronous, the agent must orchestrate a delay.

"We received a GDPR deletion request for advertising ID '00000000-0000-0000-0000-000000000000'. Submit an OpenDSR deletion request to AppsFlyer. Once submitted, wait exactly 2 minutes, then check the status of the request batch to confirm it has been registered by the system."

Step-by-step execution:

1. Claude calls create_a_apps_flyer_opendsr_request, providing the IDFA and the deletion command.
2. AppsFlyer returns a 202 Accepted with a subject_request_id.
3. Claude pauses its execution context to respect the asynchronous delay.
4. Claude calls get_single_apps_flyer_opendsr_request_by_id using the request ID.
5. The agent parses the status payload and informs the user if the job is successfully queued for processing.

sequenceDiagram
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant AF as AppsFlyer API

    Claude->>Truto: Call create_a_apps_flyer_opendsr_request
    Truto->>AF: POST /dsr/request
    AF-->>Truto: 202 Accepted (subject_request_id)
    Truto-->>Claude: Returns subject_request_id
    Note over Claude, AF: Wait 2 minutes for registration
    Claude->>Truto: Call get_single_apps_flyer_opendsr_request_by_id
    Truto->>AF: GET /dsr/status
    AF-->>Truto: 200 OK (Status payload)
    Truto-->>Claude: Returns completion status

2. S2S Event Debugging and Validation

Persona: Mobile Infrastructure Engineer

When server-to-server events stop appearing in analytics dashboards, engineers need to audit the event payloads and verify the Push API configurations.

"I need to debug why our 'checkout_completed' S2S events aren't firing properly. First, send a test S2S event for app 'ios.store.app' with the event name 'checkout_completed' and a value of $0.00. Then, pull our current Push API configuration to see if 'checkout_completed' is missing from the allowed event types array."

Step-by-step execution:

1. Claude invokes create_a_apps_flyer_s_2_s_event to inject a test payload directly into the attribution engine.
2. Claude then calls get_single_apps_flyer_push_api_configuration_by_id to retrieve the active webhook routing rules.
3. The agent analyzes the returned JSON array of event_types and flags to the engineer if the specific event name is being dropped by the Push API filter.

3. Campaign Performance Audit

Persona: Growth Marketer

Growth teams frequently need to pull aggregate KPIs to shift budget allocations quickly, without navigating complex BI dashboards.

"Pull the AppsFlyer Master Report for the last 3 days for our main iOS app. Group the data by media source. Find the top 3 media sources by total installs, calculate their effective cost per install if cost data is present, and generate new OneLink tracking URLs for those top 3 sources to use in our retargeting campaign today."

Step-by-step execution:

1. Claude calls list_all_apps_flyer_master_reports, structuring the required parameters (app_id, from, to, groupings: ["pid"], kpis: ["installs", "cost"]).
2. The agent analyzes the returned dataset, isolating the top 3 performing media sources.
3. Claude iterates through the top sources, calling create_a_apps_flyer_onelink_link for each to generate fresh deep links.
4. The user receives a concise summary of the top networks along with ready-to-deploy tracking URLs.

Security and Access Control

Exposing a powerful platform like AppsFlyer to an AI agent requires strict security guardrails. Truto provides several mechanisms to lock down your MCP servers:

• Method Filtering: You can limit the MCP server to only allow read operations. If an LLM hallucinates and attempts to call delete_a_apps_flyer_app_platform_by_id, the MCP router will instantly reject the request before it reaches AppsFlyer.
• Tag Filtering: You can group tools by functional area. By configuring the server with specific tags, you ensure the agent only sees tools related to reporting, keeping administrative tools hidden.
• Require API Token Auth: By setting require_api_token_auth: true, possession of the MCP URL alone is insufficient. The client must also pass a valid Truto API token in the Authorization header, tying usage back to an authenticated team member.
• Auto-Expiration: You can set an expires_at timestamp. Once the time is reached, Truto automatically destroys the token in KV storage and cleans up the database, ensuring temporary agent sessions leave no lingering access.
• Factual Note on Rate Limits: AppsFlyer enforces strict rate limits depending on your plan tier. Truto does not retry, throttle, or apply backoff on rate limit errors. When the AppsFlyer API returns an HTTP 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. Your LLM framework or orchestration agent is responsible for catching the 429 and executing retry logic.

Empower Your AI Agents with Marketing Data

Building an integration between Claude and AppsFlyer doesn't have to require weeks of reading SDK documentation, managing API key lifecycles, and parsing asynchronous DSR workflows. By using Truto to generate a managed MCP server, you turn AppsFlyer's complex REST architecture into an auto-updating, schema-validated toolkit perfectly tailored for AI agents.

Whether you are building automated compliance pipelines, auditing SKAN configurations, or orchestrating multi-channel marketing campaigns, managed MCP servers give you the speed and security necessary to move AI out of the sandbox and into production workflows.