Skip to main content
Mobile deep linking is in Public Beta. Emulator and simulator tests do not replace Google Play and TestFlight deferred-install tests.
Test in layers. A successful API response cannot compensate for an invalid platform association, and a verified association cannot prove the store-install handoff.

1. Verify the public association files

Open these exact URLs for the Mobile App’s hostname:
Each response must be direct HTTPS 200, use application/json, stay within 128 KB, and contain the exact active app identifiers. Redirects between hostnames or from HTTP to HTTPS do not satisfy platform verification. Use Workspace settings → Mobile Apps → your app → Verify public files to compare the public documents with the expected Biqli configuration. The installed build’s signing certificate must appear in assetlinks.json. A locally signed debug build and a Google Play build normally have different certificates. When Play App Signing is enabled, include the App signing key certificate shown by Google Play for Play-delivered builds; include other fingerprints only for builds that must verify on the same domain. On Android 12 or later:
Wait for asynchronous verification before reading the result. The hostname should report verified and the final command should launch your activity. Android 15 and later can periodically refresh association changes, but propagation can take up to seven days. Android 14 and earlier normally pick up changes when the app is installed or updated. Re-verification, reinstalling, and server caches can still delay a test. See Verify Android App Links. Confirm the app has applinks:go.example.com in its signed associated-domains entitlement. Tap the link from Mail, Notes, or another application; typing it into Safari’s address bar is not the same test. The app should receive an NSUserActivityTypeBrowsingWeb activity. Apple retrieves association files through its managed content-delivery network on iOS 14 and later. Apple states that its network requests a new file within 24 hours and installed devices may check for updates approximately weekly. Reinstall the app after the association is available when testing a changed entitlement or document. See Supporting associated domains and Debugging Universal Links.

4. Test installed-app resolution

Open a mobile-enabled short URL with the app installed. Confirm:
  • the operating system launches the correct app;
  • the SDK sends the HTTPS deep link;
  • the response is exact_app_link with exact confidence;
  • the route and allowed attribution values match the current link; and
  • the app rejects an unknown route safely.
Also send a request without a deep link and verify that none is handled as a successful result.

5. Test Android deferred installation

Use a Google Play internal test track. Uninstall the app, open the Biqli link on an eligible Android device, install from the Play page reached through that click, and launch the app. Expect exact_install_referrer on the first eligible resolution. A sideloaded APK, Android Studio installation, or emulator-only flow can test the installed App Link and API, but cannot prove that Google Play delivered the referrer.

6. Test iOS deferred installation

Use a TestFlight or App Store build. Remove the app, open the link, select Continue on the Deep View, install the app, launch it, and select the explicit Biqli paste control. Expect exact_handoff. Test these negative cases too:
  • paste unrelated text and expect invalidHandoffURL;
  • let a handoff expire and expect no exact match;
  • deny consent when required and expect the SDK to stop before the request;
  • disconnect the device, start resolution, reconnect it, and retry on a later cold launch; and
  • reuse a completed handoff from a different installation and confirm it is rejected.

Common failures

Include the X-Biq-Request-Id, approximate UTC time, platform, SDK version, and match/error code when contacting support. Never send a mobile publishable key, handoff token, signed receipt, or complete attribution payload in a public support channel.