I’m writing this article because there are thousands of people who use sneaker bots and don’t really understand what they’re doing. Sneaker bots are surprisingly complex pieces of software that automate the shoe purchasing process. A lot of people who want to get into sneaker bots tend to start by driving/automating the browser (Selenium, Mechanize, etc.). I’m going to try to explain how sneaker bots actually work by explaining what they’re trying to accomplish.
What’s a sneaker bot?
If you’re reading this, you probably know what a sneaker bot is. For the uninitiated, a sneaker bot is a complicated piece of software designed to buy shoes really, really fast. Bots are meant to be used for high demand sneaker releases. During these releases, users with bots can sometimes purchase shoes in only a few seconds. It’s almost impossible to compete with. Sneaker bots are also a huge business — bots sold online can run up to $500 depending on their feature set. The companies that build and sell these bots justify this price because users could potentially use the bot to buy and resell sneakers (a relatively lucrative venture).
Why should I care how they work?
I mean, you don’t have to care. If you don’t care, don’t keep reading. I think it’s an interesting thing to know and I tend to only be comfortable with things when I completely understand them. Bots really are surprisingly complicated, especially ones sold publicly online. They’re also pretty cool. I’ll be going over some code snippets and some theory about how websites work so you get a better idea of what bots are actually doing.
The first thing worth understanding is how websites really work. The typical website architecture has three basic layers. The first layer is called the “front-end” and is how the average user interacts with an application. You’re reading this article on Medium’s front-end right now. When you buy shoes on Adidas.com, you search for shoes using the Adidas website front-end. It’s the front-facing interface to the rest of the services that Adidas provides. Adidas wants to make it as easy as possible for you to sign up, look for the products you want to buy, and buy them. They don’t want you to have to see all the complicated information related to these operations, probably because you really couldn’t care less. For example, the Adidas purchase process should feel really smooth. When Adidas asks for your payment information, you don’t want to have to deal with making sure your information is secure or validating that you actually put a real credit card number in or any number of small details that Adidas needs to care about. They hide that from you by making the front-end as simple as possible.
Still, the front-end needs to somehow tell Adidas that you’re looking to buy a pair of shoes. This is where the “back-end” layer comes into play. We’ll also start to talk about the “data” layer. To make this as simple as possible, imagine you’re running a lemonade stand. Your front-end is the actual stand. It’s got information about prices, maybe different drink sizes, different lemonade flavors. You want to make it as easy as possible for someone to see your lemonade stand, pick their drink, and pay for the drink. In this scenario, you’re the back-end. You care about a lot more things than the person buying lemonade. You probably care about how many lemons you have left, how much sugar you have left, and who’s buying your lemonade. When someone asks you for lemonade, you handle all the processes related to making their drink and updating your information about how much lemonade you have left. The customer just wants to be able to order lemonade and walk away with lemonade.
So the best way to imagine bots in our scenario is like a literal lemonade buying robot. Imagine your lemonade has gotten really popular. Let’s not talk about what you’ve probably been putting in the stuff. You’re terrible at managing lines, so people just stand outside your lemonade stand and shout their orders at you until they get their lemonade. Someone decides that they’re tired of shouting and builds a lemonade-order-shouting robot. See, robots don’t get tired of shouting and robots know exactly what to shout in order to get your attention. Plus, with so many people trying to order lemonade, the average person can’t even shout loud enough to be heard by you.
Bringing it together
This is what sneaker bots do. Bots don’t care about a human useable front-end. Why bother? When we build bots, we look at what the front-end is trying to tell the back-end (called a “request"). Then we copy that request and automate it so we can send that request over and over again, really fast. This is like our shouting robot that knows exactly what to shout and doesn’t get tired of shouting. We don’t even need to worry about a physical browser because we know what the front-end is trying to tell the back-end. Packages like Python Requests allow you to make these requests very easily. Most (good) sneaker bots don’t even think about a browser or a website. That just takes extra resources and time that aren’t worth thinking about. We go directly to the back-end and tell it what we’re trying to do in the format that it expects.
Actually automating a request
I’m going to go through a quick example of automating the login process for a website (StockX in this case, because I already had it ready to go).
The first step of this process is to actually go onto stockx.com and open up the login page. We’ll want to actually log in but first we want to make sure we can see what happens when we log in. There’s a lot of ways to do this, but I find the easiest way is to hit F12 (or whatever button) to open the inspection pane for your browser. I’ll be using Chrome. We’ll want to open up the “Network” tab and hit the “Preserve Logs” checkbox just to be safe. This just ensures that a redirect doesn’t wipe the request from the log of requests. Now we’ll login like we normally do. You’ll see a bunch of stuff happen in the Network tab when you do that, but somewhere in the mess you’ll find a request that looks something like this:
You can see that the front-end told the back-end that you’re trying to login with your email and password. The back-end came back saying your login was accepted and told your browser to set a cookie called the “jwt-authorization" cookie (think of this like a temporary login key). Now the front-end can use this key to access the information that only you should be able to see. I went ahead and wrote a stockx library in Python that shows you how you can interact with stockx without a browser or a website (purely with Python). You could use that library to write a StockX bot! I added each of the features in the StockX library by going through this process repeatedly — seeing what I need to tell StockX I order to do something and then seeing what information I get back. It’s a great resource if you learn better by reading actual code. I also have an old supreme script available here if you want to see what this looks like in practice.
That’s all I got for this article. The best way to learn how bots work is to read some of the code available online and to practice writing bots for simpler sites. Try to avoid sites with captcha when you’re starting out because it can get complicated if you’ve never done it before. I’ll post some projects on my GitHub from time to time, so be sure to follow me there to keep up with my latest work. If you have any questions or suggestions for articles you’d like me to write, leave a comment!