Web-to-App Acquisition

The user arrives from an ad or a landing page, pays on the web, then installs the app. You cannot pre-identify them, so metadatas.appUserId — the join key of the app-to-web flow — is not available.

Use the email as the join key

The simplest and most robust approach:

  1. The email is entered at checkout.
  2. The webhook passes it on to you; you create an account (or a pre-registration) with the associated access right.
  3. The success page invites the download and displays the email used.
  4. The user installs the app and signs in with that same email.
  5. Your backend finds the access right.

This approach avoids deferred deep linking, fingerprinting, and any dependency on a Mobile Measurement Partner (MMP). No extra SDK in your binary, no attribution window to reason about.

Configure the session

Set returnMode to APP_INSTALL and provide your store URLs, so the success page shows the App Store / Google Play badges and the sign-in email — without an automatic redirect, since the app is not installed yet.

{
  "returnMode": "APP_INSTALL",
  "appStoreUrl": "https://apps.apple.com/app/id000000000",
  "playStoreUrl": "https://play.google.com/store/apps/details?id=com.yourbrand.app"
}

These three fields can also be set once on the subscription offer or the payment link from the Dashboard — see Creating the Checkout Session. That matters here: a buyer coming from an ad usually lands on a subscription link or a payment link, where no API call of yours is involved.

APP_INSTALL is displayed everywhere, including on desktop — which is exactly the case of a buyer who saw your ad on a website.

Matching an existing customer

To match a user with an existing Inflow customer, look them up by email:

curl https://api.inflowpay.xyz/api/customer/email/[email protected] \
  -H "X-Inflow-Api-Key: inflow_prod_your_key"

Related


Did this page help you?