Ordering Biryani Without Missing a Six: The Swiggy × JioHotstar Story

Picture this: Your favorite batsman is on strike, two runs needed off the last ball — and you’re starving. Do you close the match to open a food app? Of course not. Nobody does. (Blame our laziness 😅)

That’s the exact problem Swiggy and JioHotstar set out to solve: let users order food without ever leaving the JioHotstar app. The ask sounded deceptively simple. The reality? It was one of the most challenging, cross-company, deadline-driven integrations I’ve been part of in my career.

Quietly baked into this project was a second goal: use it as a launchpad to close the gap between Swiggy’s web experience and the native app. www.swiggy.com already handles roughly 5% of Swiggy’s total orders — enough volume to launch a startup in its own right — but the web had always been a step behind the app. This integration gave us the pressure, the scope, and the mandate to finally close that gap. (We also support Swiggy as a PWA at 3–4 MB, compared to 35 MB on Android and 140 MB on iOS — a meaningful option for users who’d rather not install yet another app.)

The “Quick Fix” We Didn’t Take

The first idea on the table was the obvious one: when a JioHotstar user taps “Order Food,” just deep-link them straight into the Swiggy app. That thinking is a business-first viewpoint.

Both teams pushed back immediately, and rightly so. We are always strinving, to be user first, even if it increases the complexity. If you’re watching a match in split-screen, the last thing you want is to get yanked into a different app — breaking your session, losing your context, maybe missing a wicket in the process.

So we committed to keeping the user inside JioHotstar entirely, with www.swiggy.com running in an embedded WebView. It meant significantly more engineering work. It also meant a genuinely seamless experience — and that was the whole point.

Eight Weeks, Two Companies, One IPL Season

When the project kicked off, we were equal parts excited and nervous. Cross-company work always has its own flavour of chaos: different tech stacks, different release cycles, different mental models for the same problem.

The initial scope seemed manageable enough: render the full www.swiggy.com ordering journey inside the JioHotstar app. Then the dependency list started growing.

What started as a two-engineer frontend effort expanded to five. Fast. The scope kept widening:

1. Authentication bridge between two entirely separate identity systems
2. Encrypted phone number sharing (more on this shortly)
3. Split-screen layout overhauls for a viewport smaller than any mainstream phone
4. GTM instrumentation for cross-company analytics
5. Rate limiting to protect Swiggy’s core traffic from IPL-sized spikes
6. SMS OTP coordination between two separate telecom and product systems
7. Location sharing between both apps
8. Inline app install on android using the google framework

These weren’t parallel workstreams you could hand off independently — they were a deeply tangled dependency graph. Auth couldn’t be tested until the WebView bridge (the communication layer between the native JioHotstar app and Swiggy’s web layer) was stable. Layout changes couldn’t be finalised without real devices running the actual JioHotstar build. Location sharing couldn’t be validated until JioHotstar’s integration layer was ready on their side.

IPL was eight weeks away. We got moving.

Build the Playground Before You Build the Product

The single best decision we made early on: don’t touch the actual product until you’ve built a playground first.

Cross-company integrations have a particularly cruel failure mode. Both teams think they understand the contract. Both teams build to their understanding. Integration breaks in production — because the mental models were almost right, but not quite. By the time you find out, you’re days from launch with no slack left.

We built a dedicated playground page that surfaced every integration touchpoint in isolation — no auth, no checkout, no restaurant listings. Just raw, inspectable signals. When JioHotstar opened the WebView with query parameters, the playground rendered every single one of them on screen. We could verify in minutes whether the data shape we’d agreed on paper matched what was actually being sent.

This sounds obvious. Most teams skip it under schedule pressure. We didn’t — and it saved us weeks.

A problem caught in the playground was an hour of work. The same problem caught in production, during a live match, with real users, was a rollback.

What we specifically validated

Deeplink parameters: Before writing a single line of product code, we rendered everything JioHotstar sent us directly on the playground page — confirming the right shape, the right encoding, the right fields were all flowing correctly.

Refresh and tab-switching: Users constantly switch tabs during a match. We needed context to survive those transitions, and background polling to keep running (so we could serve better offers the moment a six was hit). A small playground test — set a value, navigate away, come back, check it’s still there — gave us confidence before wiring up the full flow.

Location sharing: Probably the most complex piece of the whole integration. The playground let both teams independently verify the location handshake end-to-end, without needing the full product in place. Given how many iterations this went through, having that isolated test surface was invaluable.

The playground saved us weeks of debugging and redundant cross team work.

Getting Location

Location is what connects a hungry user to a biryani place 800 metres away. Getting it wrong isn’t just a bad experience — it’s a dead end.

First, we show a Swiggy-branded popup asking the user to allow location access. Then — only after they say yes to that — we trigger the native OS permission dialog. The reason: if a user dismisses the native popup once, Android and iOS mark the permission as denied and will never surface that dialog again. By putting our own popup first, we give the user context and intent before the one-shot native prompt appears. A warm-up, not a cold ask.

Once we have the location, the flow forks:

Logged-in user: We match the detected location against their saved addresses within a cutoff radius. If there’s a nearby match, we use it — no friction. Otherwise it’s treated as a new location. Logged-out user: We skip the matching step entirely and go straight to showing restaurants. No account, no problem.

If location access is denied, we fall back gracefully: the user is prompted to select their address manually.

The edge cases are where things get platform-specific. On Android, if a user previously denied location and tries again, we redirect them to the app settings page — at least they can fix it themselves. On iOS, there’s no such redirect. The user is simply stuck until they manually navigate to Settings → JioHotstar → Location and reset it themselves.

Fitting Swiggy Into Half a Screen

Here’s a number: the JioHotstar split-screen WebView gave Swiggy less than 50% of an already-small mobile viewport. That meant major rework across the entire ordering flow.

Everything we’d built for www.swiggy.com was designed for full-screen mobile — larger cards, breathing room, layouts that assumed a normal phone screen. None of that held up in a split-screen context. So we went page by page and asked: what does the user actually need to see right now?

Keyboard handling

On standard screens, most of our input boxes sit near the top of the page — so when the OS keyboard pops up, everything stays visible. On a constrained viewport, the keyboard swallowed the input entirely. Users were typing delivery addresses they couldn’t see. Terrible experience.

Our fix: the moment a user taps an input, we hide the top header (reclaiming that space) and scroll the input into view by appending a div at the bottom equal to the keyboard height. Simple in principle, fiddly in practice — but it works, and users never notice the machinery.

Scroll behaviour

With limited vertical space, we didn’t want the header permanently eating into the restaurant list. We adopted a hide-on-scroll-down, show-on-scroll-up pattern. More of what the user cares about stays visible; navigation chrome steps aside until needed.

Resizing everything else

Previous (Left), Current (Right)

We went through every screen — restaurant listing, restaurant detail, cart, checkout — and systematically cut what didn’t need to be visible at first glance. The results were meaningful. On the restaurant collection page, we went from showing 2 restaurants in the first fold to 6. That’s not a minor UX tweak; it’s the difference between a user feeling like there’s real choice to browse versus staring at a large screen and giving up.

A new layout built for this context

A user arriving from inside JioHotstar has a completely different context than someone opening www.swiggy.com directly — different intent, different screen space, different expectations. We built a dedicated layout for this flow, hosted on a separate route so we could measure load times and web vitals independently.

Swiggy’s frontend uses a server-driven (PL-presentation layer) system: the backend sends an ordered list of cards, each with a type, and the frontend renders the right widget and wires up the right interactions based on that type. https://medium.com/swiggy-bytes/swiss-knife-that-powers-the-swiggy-app-dff9dc49a580 We leaned heavily on this for the JioHotstar layout — new page, familiar machinery, much faster to ship than building bespoke APIs from scratch.

Logging In Without the Friction

Authentication was where the two-company reality hit hardest. JioHotstar and Swiggy are separate companies with entirely separate identity systems. No shared auth platform, no single sign-on magic wand. The user has to log in to Swiggy to order.

But “has to log in” doesn’t have to mean “has to do anything.” We engineered the friction almost entirely away.

Sharing the phone number, safely

JioHotstar knows who their user is — they have the phone number. The obvious move: pass it in the WebView URL. The problem: Passing it in plaintext meant other webviews in JioHotstar app could potentially have been able to query and receive data meant for Swiggy despite JioHotstar having guardrails around access.

The keys are shared beforehand asynchronously, so that it never goes over the network.

So we used RSA encryption. JioHotstar encrypts the phone number using Swiggy’s public key before it ever touches the URL. Swiggy decrypts it server-side using the private key. Even if another ad SDK, a proxy, or a log ingests that URL — all they see is ciphertext that’s mathematically useless without Swiggy’s private key.

Getting the key exchange right — rotation strategy, encoding formats, timing of decryption — took significant back-and-forth between the teams. None of it is trivial under a deadline. But getting it wrong meant either broken logins or a privacy incident on launch day. Worth every hour.

Auto-reading the OTP

Android supports an https://developer.android.com/identity/sms-retriever#start-sms-retriever that lets an app automatically read an incoming OTP — but only if the SMS contains a hash specific to the receiving app. Swiggy and JioHotstar each had their own SMS templates, so out of the box, neither could read the other’s OTPs.

The fix was coordination: Swiggy added the JioHotstar app hash to our OTP SMS format; JioHotstar updated their parsing to handle Swiggy’s SMS structure. Now the OTP gets read and pre-filled automatically — no copy-paste, no app-switching, no manual action at all. Both the phone number screen and OTP screen support auto-submission with a short delay. The user just watches it happen.

iOS doesn’t support background SMS listening, so on iPhone the user taps the OTP suggestion above the keyboard. It’s a lesser experience — and there’s genuinely nothing that can be done about it at a platform level — but it’s still far less friction than a fully manual login.

Sharing Data Across Companies

Getting users to order is only half of a successful partnership. The business teams on both sides need to understand what’s actually happening — conversion rates, drop-off points, what’s growing and what isn’t.

We used https://tagmanager.google.com/ to pipe analytics events from Swiggy into JioHotstar’s data systems. GTM lets us change what we track without a full release cycle, which mattered a lot during the early weeks when requirements were still shifting.

One hard rule, though: GTM is powerful because it can inject arbitrary JavaScript into a page. That’s precisely what you don’t want near a user entering payment details. We enforce a strict policy — GTM is never initialised on any payment page. The tracking pipeline goes dark the moment checkout begins. No analytics signal is worth the attack surface.

GTM is an excellent tool to share data with cross team, just make sure it’s removed at the right places.

Making Sure the Servers Don’t Miss a Six Either

Keeping JioHotstar traffic from taking down Swiggy

The service powering the JioHotstar WebView is the same one powering www.swiggy.com and several in-app webviews inside the Swiggy native app. A sudden spike from an IPL moment — Bumrah takes a wicket, a million users suddenly want biryani — could overwhelm the service and take down Swiggy’s core traffic too. That’s a non-starter.

We separated JioHotstar traffic at the load balancer level. JioHotstar WebView requests route to dedicated downstream instances with their own auto-scaling policies — policies tuned to IPL match schedules, not general web traffic patterns. When the spike comes, it lands on infrastructure built specifically for that moment, isolated from the rest.

Rate limiting, two ways

We apply two layers of rate limiting for JioHotstar traffic.

The first is per-IP rate limiting, which has existed in Swiggy’s stack for a while and catches bots and abusive request patterns before they cause damage.

The second is JioHotstar-specific service-level rate limiting — a circuit breaker ensuring that even a massive IPL-driven traffic surge can’t compromise Swiggy’s core app flow.

When rate limits do kick in, we don’t show a generic error page. A user hitting a limit during a live match has a clear context and intent — so we built a custom error page that leans into the IPL theme, rather than making it feel like something went wrong.

Overall, be very sure about your traffic strategy, as that’s the difference between a good experience, and the oncall getting harassed.

What We Shipped

Eight weeks. Two companies. One IPL season.

Millions of users watching a match and ordering food without switching apps, logging in manually, missing a ball, or noticing any of the machinery underneath. That’s the goal — make the engineering invisible.

None of this happened without the people who built it: Nishant Fulara, Ashigupta, Shivam Bhasin, Himanshu Ranjan Dwivedi, Taruun Malik who held the line through weeks of late nights and cross-team dependencies.

And to the frontend leadership Rahul Dhawani, Rooheen Garg, Tushar Tayal who were there to support through the journey, for any concerns.

Special thanks to everyone who kept the whole experience together: Mehar, Shreenath, Ankush, Aaryan, Karthiga, Shikhar, Manu, Bhavesh, Himanshi, Priyam, Nitish, Mohit, Smit.

The integration is live. The cricket is on. Get ordering.