Product

Context forwarding,
not attribution theater.

Forwarded carries a signed, server-backed JSON payload from any web page through a mobile app install or open — using only what iOS and Android already provide. Unlike attribution SDKs that guess at identity through device fingerprinting, Forwarded delivers your payload deterministically or tells you exactly why it couldn't. The payload is yours; Forwarded is just the pipe.

No credit card required · iOS + Android · Webhook delivery included

The gap

Your install funnel has a dead zone.

Every mobile app has an install gap: the moment between a user tapping a link in a browser and their first session inside the app. The context that brought them there — a referral code, an invite, a deep-link target, a campaign offer — evaporates the instant the App Store or Play Store is in the middle. Existing solutions paper over this with probabilistic device fingerprinting or require the user to already be authenticated, neither of which works reliably for onboarding flows where context matters most.

Attribution theater

Probabilistic fingerprinting works until it doesn't. Browser privacy changes, VPNs, and shared IP addresses routinely break IP-based matching at exactly the scale where it matters most. Most attribution SDKs silently report a match anyway — leaving you with inflated numbers and no way to tell good data from bad.

Login-gate workarounds

Requiring a user to log in before resolving context defeats the entire point of a seamless install flow. Invite links, referral codes, and partner offers need to work before signup — that's what makes them valuable. Gating resolution on authentication trades the hardest part of the problem for the appearance of having solved it.

Platform context, ignored

iOS has supported the app-argument field in Smart App Banner since iOS 6. Android's Install Referrer API has been stable since 2017. Most teams don't use either because building the session management layer — signing, expiry, state tracking, SDK distribution — takes weeks and isn't core to the product.

How it works

One session. Four states.

A Forwarded Session is a signed, server-stored JSON payload attached to a public link — up to 8 KB of developer-defined content that travels through the install gap without touching device identity. Its state moves from CREATED through OPENED, RESOLVED, to CLAIMED as the user progresses from web visit to install to signup.

CREATED
OPENED
RESOLVED
CLAIMED
CREATED

When a user visits the Forwarded Link, a session is created server-side before the page is rendered. The session contains your payload, a signed HMAC token, a nonce, and an expiry. The landing page is served immediately — no redirect and no round-trip the user can observe.

OPENED

The user taps the Smart App Banner, follows a Universal Link, or Google Play delivers the referrer string to the newly installed app. The session is marked OPENED with the exact platform mechanism and timestamp recorded. This is the moment context crosses from web to native.

RESOLVED

The native SDK reads the token from the app-argument, install referrer, or incoming Universal Link URL. It calls the Forwarded API, which validates the HMAC signature, checks expiry, and returns your payload along with the determinism tier and mechanism used. No payload data is stored in the token itself.

CLAIMED

After account creation or login, your code binds the resolved session to a known user with a single API call. The session is permanently associated with an external_user_id of your choosing. Idempotency keys on the claim endpoint make retries safe even across network failures during signup.

Platform mechanisms

Deterministic paths, not guesses.

Forwarded is built on top of what Apple and Google already ship — mechanisms designed specifically for passing context between a web page and a native app. The session management layer handles signing, expiry, state transitions, and SDK delivery so you don't have to build any of it yourself.

iOS

  • Smart App Banner app-argumentdeterministic
  • Universal Linksdeterministic
  • URL scheme fallback

The Smart App Banner app-argument attribute lets the web page embed an arbitrary string that iOS passes directly to the app on open — no redirect, no third party in the middle. Forwarded uses this field to carry the session token, which the SDK reads before your first frame renders. When Universal Links are configured, the token arrives in the incoming URL with the same guaranteed delivery semantics.

Android

  • Google Play Install Referrerdeterministic
  • App Linksdeterministic
  • Explicit token fallback

The Google Play Install Referrer API gives a newly installed app the exact referrer string from the Play Store link that triggered the install — delivered by Play itself, not inferred from network signals. Forwarded encodes the session token into the referrer parameter at link generation time and reads it back in the SDK before any user interaction. App Links provide the same token path when the app is already installed.

Every resolved session includes a mechanism field identifying the exact platform path used — smart_app_banner, universal_link, install_referrer, and so on — alongside the determinism tier. You have the full picture of how context arrived, not just that it did.

First-class classification

Every resolution is labeled.

Forwarded reports the mechanism and confidence tier alongside every resolved payload — not as metadata you have to opt into, but as a first-class field in every API response. You always know whether a payload arrived deterministically or through a lower-confidence path. Lower-confidence resolutions are never silently upgraded to look like deterministic ones.

Deterministic
  • ·iOS Smart App Banner (app-argument)
  • ·Universal Links
  • ·Android Install Referrer
  • ·App Links
  • ·QR direct token
  • ·Manual code entry

These paths guarantee one-to-one binding between the web click and the app open. The token travels through platform infrastructure, not network heuristics.

Lower confidence
  • ·Generic App Store redirect
  • ·Unsupported in-app browser
  • ·Unknown platform

Forwarded labels these honestly. You decide whether to act on them in your application logic. They are never quietly reclassified as deterministic to make numbers look better.

Built for developers

SDK, API, and webhooks — nothing else required.

Forwarded ships everything needed to go from zero to a working session in a single afternoon. The surface area is intentionally small: two native SDKs, a REST API with five endpoints, and webhooks for the lifecycle events you care about.

Native SDKs

Swift Package for iOS. Kotlin library for Android. Configure once at app startup with your workspace key. One method call to resolve a session, one call to claim it after the user is known. No third-party tracking, no analytics beacons, no data collected beyond what the session requires.

REST API

JSON API under /api/v1. Authenticate with a scoped API key per environment. Resolve and claim endpoints accept idempotency keys, making retries safe across any failure mode. Errors return machine-readable codes and a request_id — no stack traces, no implementation details at the boundary.

Webhooks

Forwarded delivers session.resolved, session.claimed, and lifecycle events to your endpoint. Payloads are HMAC-SHA256 signed. Failed deliveries retry on a bounded schedule — 1 min, 5 min, 30 min, 2 hr — and dead events remain inspectable in the dashboard so nothing is lost silently.

Observability

Every session, inspectable.

Forwarded keeps a full audit log of every session — from creation through claim — with exact timestamps, platform mechanism, and delivery outcome for each event. You can answer “what happened to that session” without reading application logs.

Session inspector

Look up any session by token or external user ID. See the full lifecycle: when it was created, the platform it was opened on, when it was resolved, and which user claimed it. Directly useful for debugging referral attribution in production.

Event timeline

Every state transition is timestamped to the millisecond and stored with the full request context — mechanism, determinism tier, IP (hashed), and SDK version. The timeline is append-only; no events are backdated or retroactively modified.

Webhook delivery log

Every outbound webhook attempt is logged with the HTTP status from your endpoint, response body (up to 1 KB), latency, and retry schedule. Failed deliveries can be manually replayed from the dashboard after you fix your endpoint.

Start forwarding context today.

Create a workspace, register your app, attach a payload, install the SDK. The first Forwarded Session can be working in under 30 minutes.

No credit card required. iOS + Android supported. Webhook delivery included.