I wrote a service to automatically swipe right on Hinge profiles.
To accomplish this, I needed to figure out what a request from my mobile phone to the Hinge servers looked like.
Modern web browsers, like Chrome, make it easy to view the content of each request made in your browser. If you’ve never tried it, you can press
Cmd + Shift + I while on your favorite website, and watch as a flurry of advertising trackers communicate from your computer to a server elsewhere. If we’re able to view the requests our computer is making to a server, we can run those same requests outside of their intended environment. For example, perhaps you’d like to write some code to categorize all your emails. If the email service doesn’t offer a public API, it’s up to you to reverse engineer the request your browser makes so you can replicate the behavior of the request on your own terms.
But while it’s easy to view external network requests happening on a browser, it’s harder to do that when the requests are being sent directly from your laptop or mobile phone.
In order to view the network requests being made from a phone, we can’t send our requests from the phone to the server directly. Instead, we need to forward our requests to a proxy which intercepts the data before forwarding it to the original server it’s intended for.
Luckily, this paradigm has a name, and it’s called man-in-the-middle (or MITM). I’ll show you how I setup a MITM proxy in the next section.
Setting up a Man-in-the-Middle Proxy
Since I need to know how exactly my phone requests data from Hinge, I need to forward all requests to my laptop, which will display the request content on my computer before sending them off to Hinge as intended.
Here’s how I set it up:
Man-in-the-middle proxy is a service that lets us intercept all outgoing traffic from our phone onto a laptop. The setup is easy.
- In your terminal, run
mitm proxy- make sure to record the port the service is listening to.
- Download and install a certificate on your phone from mitm.it.
- In your phone settings, click WiFi -> your current network -> info -> configure proxy -> manual -> and enter your laptop’s IP address and the port from #2.
Now, you should start seeing requests pop up in your terminal. These are the same requests your phone is making, but now you can see what’s actually going on in the background!
Now we’re ready to get to work.
How the Hinge API Works
With MITMP displaying network requests from my phone, I logged into Hinge and watched the requests pop up in my terminal.
Viewing outgoing network requests from my phone, on my laptop
Hinge uses a few services to make your online dating experience possible - login happens through Facebook, and the entire messaging feature is actually not handled by Hinge, but outsourced to a third-party service called SendBird. When I clicked messages, I watched as all my messages were retrieved by referencing something called a
channel_id in SendBird.
But, let’s not lose sight of the big picture. I’m here to automate swipes, and messaging is out-of-scope for now.
I returned to my terminal, and started watching the requests more carefully. When you first login to Hinge, the app retrieves a list of user profiles that it displays in your feed. These are the profiles you swipe on.
If Hinge has a suggested match for us, that’s the first user displayed in our feed
However, this API only displays profile IDs for each user in our feed. To get the content of each profile, we need to call a separate endpoint with the list of users that Hinge wants to show in our feed.
Not bad, eh?
Anatomy of a Swipe
When we swipe right on a profile, we send Hinge a few pieces of information: the ID of the user we’re rating and the photo we’re “liking.”
What a “right swipe” looks like to a server
The rating returns the number of swipes remaining. Since I have a premium membership with unlimited swipes, the number of swipes remaining is -1. If I had a free account, the number of swipes remaining would be between 0 and 10.
Putting It All Together
Now that we know how the Hinge service works under the hood, we can tie our pieces together to create an auto-swiping service.
- Get a list of profiles
- Get content for each profile in the list
- Rate each profile in our list, referencing one of the photos in each profile
I wrote the service using less than 100 lines of Python, and it works quite well. We get 20 profiles at a time, and swipe right one-by-one, with a 1-5 second delay between each swipe.
All of the swipes
You’re probably wondering: won’t indiscriminate swiping result in worse matches? Fortunately, Hinge lets us customize our match preferences on the app iteself. Although this criteria is based on a user’s demographic data (education level, ethnicity, work, etc.), some of these criteria correlate well to attractiveness, and I was able to tweak my settings so that >75% of my matches are people I’d swipe right on manually.
So far, being bombarded with low quality matches from automatically swiping right hasn’t been an issue, but you should experiment with different criteria until the average profile in your feed is someone you’d swipe right on.
When we login to Hinge for the first time, we login with our Facebook account, which returns us an ephemeral token that is sent to Hinge to generate a persistent token that never expires. Unless we log out of Hinge, this access token will remain valid. Since I wanted my service to work as flawlessly as possible, I included this flow in the script, so that we don’t need to manually extract the access token from Hinge each time we log out.
Now, if our Hinge access token is expired, our script uses our Facebook credentials to request a new access token, which we send to Hinge to receive a persistent token that allows us to make authenticated requests.
MITM proxy makes it easy to reverse engineer your favorite mobile apps so you can learn about how they work under the hood.
Whether its Hinge, Snapchat, or Uber, it’s worth experimenting with
MITM proxy to understand how the internet works, and how a simple exchange of structured data enables us to enjoy remarkable experiences on our phones.
From a more meta standpoint, I’m fascinated by our emerging world of algorithmic dating, and it doesn’t seem like we’re very far off from having apps know our preferences and make match recommendations without any input from the user whatsoever.
Today, over 40% of couples meet online. I can’t help but wonder how long it will take for the first couple to be matched through 100 lines of code.