Deep Linking for Indian Apps: Flipkart, Zomato, Swiggy, Nykaa & CRED

Deep linking sends a user straight to a specific screen inside an app — a product page, a restaurant menu, a category listing — instead of dumping them on the app's home screen or a browser. For an Indian marketing team running QR codes on packaging, flyers, standees or delivery boxes, this is the difference between a scan that converts and a scan that makes the customer search again.

The practical work is almost entirely about fallbacks. A deep link that works beautifully on an Android phone with the app installed can dead-end on an iPhone without it, or on a desktop browser. Getting deep linking right for Indian apps means planning for four situations, not one: app installed on Android, app installed on iOS, app not installed, and desktop.

There are three mechanisms in play, and mixing them up is the source of most broken campaigns:

• Android App Links. An https:// URL that Android can route directly into the app when the app has verified ownership of that domain. If the app isn't installed, the same URL simply opens in the browser — which is why this is the most robust option. Most large Indian apps support this on their own web domains.
• iOS Universal Links. Apple's equivalent: an https:// URL that iOS hands to the app when installed, and opens in Safari when not. Same graceful-fallback property as App Links.
• Custom URL schemes (flipkart://, zomato://, swiggy://, cred://). These are app-specific protocols. They work reliably only when the app is already installed — and when it isn't, the browser typically shows an error or does nothing at all, which is precisely the dead end you must avoid on printed material.

The practical rule for printed QR campaigns: prefer the app's own https:// web URL. Modern Indian apps route those into the app when installed and fall back to a working mobile web page when not — which is exactly the behaviour a printed code needs, since you cannot know what the scanner has installed.

Rather than treating every app the same, it helps to know the general shape of each:

• Flipkart. Product and category pages on the Flipkart web domain route into the app on Android when installed, and render a full mobile web product page when not. For seller and brand campaigns, linking the canonical product URL is almost always better than a scheme link.
• Zomato and Swiggy. Restaurant and store pages exist on the web with a working mobile experience, so the web URL degrades gracefully. This matters especially for restaurant QR campaigns, where a meaningful share of scans come from customers who have only one of the two apps installed.
• Nykaa. Product and brand pages have full web equivalents, making web URLs the safe default for packaging inserts and influencer campaigns.
• CRED. More gated than the others — much of the experience assumes an installed, onboarded app. For CRED-adjacent campaigns, an app store link with a clear on-page explanation usually performs better than attempting a deep link that most scanners cannot follow.

The honest caveat worth stating: each app's deep link behaviour is controlled entirely by that app, and it changes without notice. URL structures get rewritten during redesigns, App Link verification gets updated, and a link pattern that worked last quarter can silently start failing. Always test on real devices shortly before a print run, and re-test periodically for long-lived printed material.

Every deep-link campaign needs a defined answer for all four cases. Write these down before you print anything:

The third row is where most campaigns lose people. Sending an uninstalled user straight to an app store listing feels efficient, but it drops them into a download flow with no context about the product they just scanned for — and after installing, they land on the app's home screen, not the page you intended. For most Indian retail and F&B campaigns, the mobile web page converts better, with an in-page app prompt if the app experience is genuinely superior.

The fourth row matters more than people expect, because QR codes get photographed and opened later, and links get shared into WhatsApp groups and then opened on laptops.

Printing a raw deep link into a static QR code creates two specific problems, and both are expensive.

First, deep link URLs are long. A Flipkart product URL with tracking parameters can run well past 150 characters, which produces a dense, small-module QR code that scans poorly from packaging or a standee. Our data capacity guide covers why that happens.

Second, app URL structures change. When an app redesigns its URL patterns or a product SKU is discontinued, every printed code pointing at the old structure becomes a dead end — and there is no fix short of a reprint.

A dynamic QR code solves both at once. The printed pattern encodes a short SMLLR link; the destination lives in the dashboard and can be updated at any time. If Flipkart changes its URL format mid-campaign, you update one field and every carton, flyer and shelf-talker already in the market starts working again. Our app deep linking guide covers the setup in detail, and deep linking explained covers the concept from the ground up.

SMLLR's device-based redirect rules let a single QR code send iOS users, Android users and desktop users to three different destinations — which is the cleanest way to handle the fallback matrix without relying on each app's own behaviour.

The typical setup for an Indian app campaign:

• Android → the app's Play Store listing, or the web product URL if you'd rather the app-link handoff happen naturally.
• iOS → the App Store listing, or the same web URL.
• Desktop → a landing page with campaign context and a QR code to continue on mobile.

Device-based redirects are available from the Basic plan (₹1,999/month) upward. Our smart routing guide covers how the rule engine evaluates device rules alongside scheduled and scan-limit rules.

A word of caution: device routing is a useful safety net, not a replacement for testing. It tells you the platform, not whether the app is installed — only the app's own App Link or Universal Link handling can do that.

Deep linking fails quietly, which makes testing non-negotiable. Before committing to print:

• Test on a real Android phone with the app installed, and on one without it.
• Test on a real iPhone in both states. Simulators and desktop browser emulation do not reproduce App Link or Universal Link behaviour.
• Test at least one entry-level Android device, not only a flagship — a large share of Indian scans come from budget handsets.
• Test the link opened from inside the WhatsApp in-app browser, not just the system browser. In-app browsers handle app handoffs differently and this is how a large share of shared links actually get opened in India.
• Test the desktop case by pasting the link into a laptop browser.
• Confirm the destination page is genuinely mobile-usable — a deep link into a slow or broken mobile page is worse than no deep link.
• Re-test before every reprint, and periodically for long-lived packaging, since app URL structures change without notice.

For most Indian campaigns the winning pattern is straightforward: encode a dynamic SMLLR QR code, point it at the app's own https:// web URL so installed users get the app and everyone else gets a working mobile page, add device-based routing when you need genuinely different destinations per platform, and test all four fallback cases on real devices before printing.

That combination survives the two things that break printed deep-link campaigns — an app changing its URL structure, and a scanner who doesn't have the app — without a reprint either time.

Create your QR code on SMLLR, set your destination and device rules in the dashboard, and update them any time an app's link structure changes underneath you.