Domains and mobile links

A short-link domain controls the public URLs people open. The API endpoint controls where SDK requests go. These can be different hosts; copying your branded domain into SDK configuration is only correct when that host actually serves the API.

Connect a domain

Add the hostname in the workspace's Domains screen and follow the exact DNS instructions shown there. Wait for verification and certificate provisioning. Use a domain you control; do not guess a shared CNAME target from another installation.

Choose the link path (/l by default, or /r where configured) before distributing links. A verified domain ID can be used in server link creation. The returned shortUrl is the canonical public URL.

iOS Universal Links

Register the actual Apple team ID and app bundle ID in the workspace. Add the link domain to the app's Associated Domains entitlement using applinks:<hostname>. The domain must serve /.well-known/apple-app-site-association with the expected app identifiers and path rules.

Forward incoming Universal Links to the iOS SDK, or to your React Native, Expo, or Flutter integration. Route only to app paths your application supports.

Test an installed signed build on a physical device. Association caching and the context used to open a URL can affect behavior. Browser navigation alone does not prove Universal Links are configured.

Android App Links

Register the actual Android application ID and SHA-256 signing fingerprints. Use the certificate that signs the distributed build; with Play App Signing this can differ from your upload certificate.

Configure the app's HTTPS intent filters and verification for your link domain and path. The domain must serve /.well-known/assetlinks.json with matching application and certificate data. Forward received intents to the Android SDK or your wrapper.

Test both a cold start and an already-open app on a physical device. Validate the release certificate as well as your local development build.

Fallback and first launch

Set the web destination, optional iosUrl and androidUrl, and optional appPath on the link. Test behavior with and without the app installed. Platform store navigation does not itself guarantee a deferred match after installation.

Use supported install referrers, explicit referral codes, and configured matching policy. See client API and the platform SDK guides. Do not add silent clipboard reads or advertising identifiers as a workaround.

Troubleshooting

• Wrong app: check bundle/package identifiers and the correct workspace registration.
• Link opens in browser: inspect association files, signing identity, path, and device association state.
• Resolution returns 404: verify host, configured link path, workspace, archive status, and expiry.
• App opens but route is wrong: check appPath, the link listener, and your app's allowed route mapping.
• No attribution: check consent, genuine click token, privacy signals, fraud rules, and attribution window separately from routing.