How we built a web-app on top of Tinder that allows you to add your friends to your Tinder matches.
Update October 2020: This web-app is no longer maintained.
For us, Tinder can be a roller coaster of amazing dates, awful dates, unrealistic expectations, pleasant surprises, validation, and disappointment. We find it much more fun to swipe and message on your friends’ phones, perhaps because it distances you from expectations and consequences.
But what if you there was an app where you could add your friends to your matches, and they can message on your behalf? You could outsource your messaging!
This is what we set out to do when creating GroupTinder. In retrospect (and from talking with people), the name is misleading and branding catastrophe. GroupTinder allows you to add your friends as participants to your matches and grants them the ability to write messages — in your name. It’s a scary and ethically dubious concept for privacy reasons and for potential for abuse, so please use responsibly.
How does it work?
You login with your Facebook or Google account. Upon logging in, you’ll be presented with the option to connect your Tinder account through SMS verification. This step is optional, but you’ll only be able to see your own Tinder matches if you connect your Tinder via SMS.
Upon logging in, you will be taken to the home page. At first, this page will be empty, but as your friends add you to their matches, these matches will show up here.
If you connect Tinder, your matches from the last 4 weeks will appear. You can then start messaging people and viewing their profiles.
You can then add friends to conversations on a match-by-match basis by using the ‘+ Wing’ button on their profiles. This will open a pop-up.
Due to the nature of Tinder’s access tokens, as well as security reasons, you must reconnect your Tinder via SMS authentication every 24 hours in order to be able to send messages from your Tinder account. This is one of the biggest downfalls of GroupTinder.
The tech side of things
This whole project was made possible by Fbessez’s Tinder API. Huge shoutout to him!
The API contains a few essential endpoints:
- GET a list of updates since a specified time. Updates consist of matches, messages, and other, more rare events (for example, someone liking your profile photo update). This is the endpoint we use for fetching new matches and messages that we then store in our own database. This action does not seem to be rate limited.
- GET a match’s profile, which contains their name, age, school, and photos. We call this every time we get a new match. We also call it periodically to keep matches’ profiles up to date. This seems to be rate limited.
- POST a message to a match. We use this to send messages.
- Additionally, the API exposes a way to acquire an authentication Token via SMS authentication. This authentication token uniquely identifies your Tinder account and is required in the headers in all of the API calls mentioned above. It’s Tinder’s way of authenticating and identifying you. To acquire this token, you have to receive and submit a 6 digit code from a sketchy French SMS. Unfortunately, this token is only valid for 24 hours, which is one of the biggest shortcomings of GroupTinder. We investigated ways to get a 60 day token, which is possible in theory. Alternatively, we could get the Tinder token via authenticating via Facebook, but this endpoint was broken during the time we were working on this app.
Given these three API endpoints, we can follow the following algorithm to maintain our own version of what’s happening on a given user’s Tinder. To make the story more compelling, suppose we have a Tinder user named Chad. Chad matches with a girl name Sasha, and adds his friend Trent to the conversation.
When either Chad or Trent enter the chat, we fetch all previous messages between Chad, Trent, and Sasha from our MongoDB database. We also periodically start requesting updates from the Tinder API. At first, we query every five seconds, but this number increases exponentially unless either party sends a message, at which point the frequency returns to five seconds. This is to reduce load on the server and to reduce the likelihood of getting banned by Tinder.
The chat uses Socket.io, a simple Node library that makes writing chat applications easy. When either Chad or Trent sends a message, or we detect a new message from Sasha, we broadcast the message to our chat room and everyone gets the message in real time. We also save the message to our database, which acts as the source of truth for messages and allows us to avoid having to query the Tinder API too far into the past.
The UI closely mimics the real Tinder. The front-end is built in React, which was a logical choice considering that there is a ton of state to keep track of. Special thanks to Erika for designing a lot of the components and recreating them in React! We learned a lot about functional components (which React is pushing for) and using ‘contexts’ instead of Redux to pass down state.
We hosted the app on AWS EC2 free-tier. It was our first time setting this up, so there was a bit of learning curve involved. Both the Node server and the React app run behind an Nginx server. We got free SSL certificates from Let’s Encrypt, which was required for Facebook https authentication.
Launching GroupTinder at our school was a hilarious experience, with 15% of my school’s student body signing up. Of the feedback we received, 90% was to work on the branding. The website never became huge, which was likely for the better. Unfortunately, the API changes frequently, and now that we’re out of school, it’s hard to find the time to keep things running smoothly, so at the time of publishing this, some core functionality is broken.
Update: As of October 2020, I no longer run this website. I don’t even own the domain grouptinder.com and because I don’t want to keep paying $12 per year. Now that I’m a full-time software engineer, maintaining compatibility with the API is too taxing, and now that I’m out of college, the idea isn’t as exciting or novel to me anymore.