Instead of asking users to define deep links themselves, Affilio automatically discovers, verifies, and stores deep link capabilities for every domain — directly from the source.

Deep links are one of those things every affiliate platform *claims* to support — until you actually have to configure them.

Most solutions expect you to manually define app schemes, maintain platform-specific link formats, and keep up when merchants change their mobile apps.

At Affilio, we took a different approach.

Instead of asking users to define deep links themselves, we automatically discover, verify, and store deep link capabilities for every domain we encounter — directly from the source.

This post explains how that works.

The Core Problem with Deep Links

When Affilio receives a new target URL like https://www.target.com/product/123, we initially don't know:

Whether a mobile app handles this domain
Which Android package or iOS bundle owns it
Whether the app supports universal links, custom schemes, or both
What the correct deep link format even is

Competitors typically solve this by pushing the problem to the user.

We solve it by treating deep links as discoverable infrastructure metadata.

Step 1: Encountering an Unknown Domain

Whenever Affilio processes a link pointing to a previously unseen domain, we mark it as unknown in our deep-link registry.

At this point:

No assumptions are made
No hardcoded rules exist
Nothing is user-defined

Discovery starts automatically.

Step 2: Inspecting the .well-known Files

Modern mobile platforms already expose domain-to-app ownership through standardized endpoints.

We query the Android assetlinks.json and iOS apple-app-site-association files hosted at the domain's .well-known path.

These files are authoritative declarations made by the domain owner.

For example, an Android assetlinks.json may reveal the exact package name claiming the domain, along with certificate fingerprints for verification.

On iOS, the equivalent file provides the bundle ID and associated domains.

This step answers the first critical question: Which app officially owns this domain?

Step 3: Fetching the App Binary

Knowing the app ID isn't enough.

The .well-known files do not expose custom deep link schemes — only ownership.

So we go one level deeper. Based on the discovered identifiers:

Android: We retrieve the APK from trusted sources (Play Store mirrors, CI feeds, or internal app caches)
iOS: We retrieve the IPA via controlled extraction pipelines and metadata feeds

At no point do we rely on documentation or third-party guesses — only real app binaries.

Security note: Affilio only inspects publicly available app metadata and declarations; no private APIs or runtime behavior are accessed.

Step 4: Extracting Deep Link Capabilities

This is where most platforms stop. We don't.

Android Analysis: We decompile the APK and inspect the AndroidManifest.xml and <intent-filter> declarations. We extract custom schemes (e.g. target://) and HTTPS app links with their host patterns. This tells us whether a scheme like target://product/123 is valid, which HTTPS paths are app-handled, and whether fallback to browser is expected.

iOS Analysis: From the IPA, we extract the Info.plist and associated domain entitlements. We record CFBundleURLSchemes (custom schemes), applinks: domain patterns, and path-level link handling when available.

In short: we learn exactly how the app expects to be opened.

Step 5: Building a Unified Deep Link Profile

Once analysis is complete, we store a normalized entry tied to the domain — covering both Android and iOS package names, custom schemes, and universal link patterns.

From this point on:

Every Affilio link targeting this domain benefits automatically
No user configuration is required
New links are deep-linked correctly on first use

Step 6: Runtime Link Selection

At click time, Affilio selects the best available deep link based on:

Device type (iOS vs Android)
App availability on the device
Platform-specific capabilities and browser behavior

Fallbacks are applied automatically:

Universal/App link (preferred)
Custom scheme (secondary)
Browser link (last resort)

This ensures links just work across every device and scenario.

Step 7: Continuous Validation

Deep links aren't static:

Apps update and change schemes
Merchants add new universal link paths
Platform behavior evolves

Affilio continuously re-fetches .well-known files, re-analyzes app binaries on new versions, and invalidates stale rules automatically.

This makes our deep-link database self-healing and future-proof.

Why This Approach Works

This system has several key properties:

Authoritative — We only trust domain-owned .well-known files and real app binaries
Future-Proof — Changes in app behavior are automatically discovered and reflected
Invisible to Users — No manual setup, no guessing, no broken deep links due to misconfiguration
Infrastructure-Grade — Deep links are treated like DNS or TLS — discovered, verified, and maintained automatically

The Result: Deep Linking as Infrastructure

At Affilio, deep links aren't a feature toggle.

They are fully automated, reliable, and continuously updated. You paste a link, and Affilio figures out which app to open, which deep link format to use, and how to fallback safely.

That's the difference — and why our users never have to touch deep link configuration.

How Affilio Automatically Discovers Deep Link Settings — No Manual Setup Required