How to Add Deep Links and Universal Links to a Mobile App

Deep links let a mobile app open a specific screen from a link: a product, booking, invitation, shared item, reset flow, or campaign. Without them, a user taps a useful link and lands on the home screen with no context.

Treat deep links as part of the product journey, not a marketing add-on.

Choose the routes that matter

Start with links that complete a real user task.

Do not build every route first. Choose the paths users will actually receive outside the app.

Understand the two main behaviors

A deep link can open the app when installed. A universal link or app link also lets the same URL open a web fallback when the app is not installed.

The experience should work in all three states:

1. The app is already open.
2. The app is installed but closed.
3. The app is not installed.

For the third state, give users a useful web page or store path, then preserve enough context to continue after installation.

Design the URL structure

Use stable, readable routes:

• yourapp.com/invite/abc123
• yourapp.com/bookings/booking-id
• yourapp.com/items/item-id
• yourapp.com/reset/token

Avoid exposing private details in the URL. Use server-validated IDs or tokens, and make expiring links expire when the action is sensitive.

Validate access after the link opens

A link is not permission. When the app receives it, the backend still needs to verify:

• Does this user have access to the resource?
• Is the invite still valid?
• Has the link expired or been revoked?
• Is the user signed in?
• Does the resource still exist?

If access is missing, explain what happened and give the user a next step. Never show a blank page or quietly redirect to the home screen.

Handle sign-in gracefully

A user may tap a link before creating an account. Keep the destination through authentication.

A practical flow:

1. User taps the shared or invite link.
2. App checks whether a session exists.
3. User signs in or creates an account.
4. App returns them to the original destination.
5. Backend confirms access before opening it.

Test this on a clean device. It is one of the most common failure points.

Use deep links for notifications too

Every push notification should open the relevant screen. Test the same link when the app is open, in the background, fully closed, or signed out.

Include a fallback if the related item was deleted, completed, or no longer available.

Add analytics without collecting more than needed

Track the route and outcome:

• Link opened
• App opened successfully
• Sign-in completed
• Destination viewed
• Core action completed

This shows whether a campaign, invitation, or notification actually helps users finish the intended journey.

Test the edge cases

Before release, test:

• A valid link on iOS and Android
• The same link in email, browser, and messaging apps
• App installed and app not installed
• User signed in and signed out
• Expired or revoked links
• A link to deleted content
• Slow network and cold app start
• Duplicate link taps

A deep-link test sheet is worth more than discovering broken invites after launch.

Build deep links in the right order

1. Pick one high-value route.
2. Define its URL and web fallback.
3. Add secure backend validation.
4. Preserve destination through sign-in.
5. Test every app state.
6. Add analytics.
7. Expand to the next route only when the first is reliable.

Build connected mobile flows with Huxly

Huxly helps founders build focused mobile apps with accounts, backend data, notifications, and the screens users need after they open an invite, shared item, or campaign link. Start with one complete journey, test it on real devices, then grow the linking system around proven flows.

FAQ