Deep Links

Deep links make URLs like https://example.com/product/123 open your app (navigating the WebView to that page) instead of the mobile browser.

1. Define rules

Admin → Deep Links → Add Rule:

Domain — usually your website domain.
Path pattern — / for everything, or scoped like /product/.
Custom scheme (optional) — e.g. myapp enables myapp://product/123 links (useful for QR codes and emails).

2. Android — App Links

Android verifies domain ownership through a file on your website.

Get your release signing certificate's SHA-256 fingerprint (see android-build.md).
Enter it on the admin Applications page (deep-link signing identifiers).
Re-download the configuration package — it now contains website/.well-known/assetlinks.json.
Upload that file to your website so it is reachable at:

   https://yourdomain.com/.well-known/assetlinks.json

Re-apply the package to the Flutter project and rebuild — the intent filters are generated automatically.

3. iOS — Universal Links

Enter your Apple Team ID on the Applications page (deep-link signing identifiers).
Re-download the configuration package — it now contains website/.well-known/apple-app-site-association.
Upload it to https://yourdomain.com/.well-known/apple-app-site-association — over HTTPS, Content-Type: application/json, no .json extension.
In Xcode add the Associated Domains capability with applinks:yourdomain.com.

Testing

Android: adb shell am start -a android.intent.action.VIEW -d "https://yourdomain.com/product/123"
iOS: send yourself the link in Notes/Messages and tap it (typing it in Safari's address bar does NOT trigger Universal Links).
Custom scheme: put myapp://product/123 in a QR code and scan it.

Troubleshooting

Link opens the browser instead of the app → the .well-known file is missing, unreachable, served with a redirect, or the fingerprint/Team ID doesn't match your actual signing identity.
Changed domains or certificates? Update the signing identifiers on the Applications page, re-download, re-upload both .well-known files, rebuild.