Set up your app's affiliate program with your AI coding agent.

Step 1: connect InfluTo to your agent

InfluTo's MCP server lives at https://influ.to/mcp (Streamable HTTP, OAuth 2.1). Terminal clients add it with one command. Editors and chat apps take the URL once in their settings.

# Claude Code
claude mcp add --transport http influto https://influ.to/mcp

# Codex CLI
codex mcp add influto --url https://influ.to/mcp

# Gemini CLI
gemini mcp add --transport http -s user influto https://influ.to/mcp

# VS Code (Copilot agent mode)
code --add-mcp '{"name":"influto","type":"http","url":"https://influ.to/mcp"}'

# Claude Code plugin: the MCP server plus two skills
/plugin marketplace add influto/influto-plugin
/plugin install influto

# Cursor: Settings → MCP → Add server
{ "influto": { "url": "https://influ.to/mcp" } }

Step 2: approve access in your browser

The first time the agent calls an InfluTo tool, your browser opens an InfluTo consent page. Sign in or create a developer account, then:

• Pick the organization. The agent can act on that organization only. IDs from any other organization return 404, so nothing leaks between accounts.

• Untick what you don't want to grant. Permissions are split into scopes such as campaigns:write, creators:write and integration:verify. New connections get all of them by default.

• Approve. The client stores the grant and refreshes it on its own; access tokens last up to an hour. You can see and revoke connected agents on the AI agent page of the dashboard.

For CI and headless runs there's a fallback: create an agent key (it_mcp_…) on the same AI agent page. It's shown once, has the same permissions as an OAuth connection and can be revoked. Send it as a Bearer header to the same URL, and keep it in an environment variable, never in the repository.

The app's SDK key (it_…) is a different key and doesn't work on the MCP server. A headless MCP config looks like this:

{
  "mcpServers": {
    "influto": {
      "type": "http",
      "url": "https://influ.to/mcp",
      "headers": { "Authorization": "Bearer ${INFLUTO_API_KEY}" }
    }
  }
}

Step 3: ask for the integration

Describe the job in your own words. A typical run goes like this:

1. 1

   Read your stack. influto_recommend_sdk maps what it finds (Expo, SwiftUI, Kotlin, Flutter, Capacitor) to the one InfluTo SDK your app needs, plus its peer dependencies. One SDK per app, not per platform.

2. 2

   Set up the account side. influto_provision creates the organization, the app with its SDK key, and a campaign in one idempotent call. influto_search_store fills in the App Store and Google Play identifiers.

3. 3

   Write the code. The scaffold tools return version-correct snippets from the SDK registry: the install line, initialize once at startup, checkAttribution at launch, identifyUser, an optional referral code field, and purchase reporting for store-direct apps.

4. 4

   Wire one validation path. influto_recommend_validation picks RevenueCat or store-direct, never both. On RevenueCat, influto_setup_revenuecat creates the webhook inside your RevenueCat project once you've pasted a v2 secret key through a dashboard link. On store-direct, you upload the .p8 key or the Play service-account JSON through a link, and the agent runs the credential check and switches the platform over.

5. 5

   Create the campaign. Commission rate, milestone bonuses and campaign copy in 11 languages. Activation needs $50 available in the wallet. If it isn't there, the agent gets a 402 and hands you a top-up link.

Then it checks its own work, which is the part that matters.

Step 4: the verify loop

An integration isn't done when the code compiles. It's done when a referred test purchase shows up in InfluTo, credited to a creator's code. The agent checks that in four moves:

1. 1

   Read the checklist. influto_integration_status returns eight steps, from app_created through sdk_initialized, validation_configured and purchase_webhook_seen to attributed_conversion, with the next actions for whatever is still open.

2. 2

   Simulate a purchase. influto_test_integration sends a $9.99 sandbox test purchase for a made-up user through InfluTo's real purchase pipeline. Pass one of your codes and you see it resolve. It's test data: it never counts in your numbers and never completes a checklist step.

3. 3

   Wait for a real sandbox purchase. You install your build through a creator's referral link (or type the code), launch, and buy with a TestFlight, sandbox or Google Play license tester. influto_recent_events shows the purchase with attributed: true and the code.

4. 4

   Confirm. When attributed_conversion_count reaches 1 from a real purchase, the integration is proven. influto_verify_user_conversions answers the same question for one app user ID.

The one step that needs your hands is the sandbox purchase on a device. The agent can check and explain everything around it. The same checks exist as plain HTTP endpoints under /api/agent for scripts and CI.

What the agent can do, and what stays with you

With the default permissions, an agent connected to InfluTo can:

• Read your program. Apps, campaigns, creators, results, the Activity feed, daily series, one creator's or one code's page, and referred subscribers by pseudonymous key only.

• Change apps and campaigns. Create and update them, including milestone bonuses, per-creator rates and translations.

• Recruit creators. Invite them one at a time or in batches of up to 500, mint join links and create free-access codes.

• Test the integration. Run the checklist, read recent events and simulate sandbox purchases.

Some things are impossible for any agent, whatever you approve: moving money (top-ups, transfers, payouts), reading or setting raw credentials, deleting data and admin actions. When a task needs one of them, the agent gets a dashboard link for you to open while signed in, to top up the wallet, upload store credentials or upload marketing assets. Secrets and money never pass through the agent or the chat.

Two more guardrails: milestone bonuses wait for review before they're paid, and the server tells agents to treat store listings, app descriptions and creator-supplied text as data, never as instructions.

67 tools, grouped by job

The tools fall into seven groups. Discovery and scaffold tools answer from the SDK registry without touching your account. The rest call the agent REST API under /api/agent, with the same permissions and organization boundaries.

The live list is the MCP resource influto://tools, generated by the server, and every tool is described at docs.influ.to/agents/tools. The server also ships five ready-made prompts: launch_campaign, recruit_creators, weekly_program_report, diagnose_attribution and fund_and_activate.

Prompts that work

Plain requests are enough. A few that map to real jobs:

• Integrate and prove it: “Add InfluTo to this app with store-direct validation and prove a sandbox purchase is attributed.”

• RevenueCat app: “This Expo app uses RevenueCat. Add the InfluTo SDK, wire the webhook and tell me what's left for me to do.”

• Launch: “Create a campaign paying 30% recurring, translate it, and give me the join link.”

• Diagnose: “Installs from MAYA's link aren't being credited. Find out why.”

• Report: “How did the program do last week, per creator?”

If anything misbehaves, ask the agent to run influto_doctor first. It needs no permissions and reports how the agent is connected, what it may do, and how fresh each app's SDK data is.

How this compares to other affiliate MCP servers

MCP servers are common in affiliate software now. Dub, Tolt, Affonso and Partnero ship them, mostly for web SaaS affiliate programs.

A mobile app needs the integration half as well: an SDK inside the app, purchases verified through RevenueCat or directly with Apple and Google, and proof that a referred purchase is credited before you invite a single creator. That loop, from picking the SDK to an attributed sandbox purchase, is what InfluTo's MCP server is built around.