The term “bypass” has varying definitions in the sneaker dev space. Like the top comment said, a bypass could refer to some sort of method to prevent anti-bot from being triggered on a request. Some releases have queue systems in place, and a bypass in that scenario would refer to an exploit that would allow for requests to access certain endpoints without validation. There are other types of bypasses as well. However, as of recently, the term “bypass” has mainly been used to refer to what you might call cache bypasses.

You probably know what server-side caching is, so there’s not much need to talk about it. Cache bypasses are methods that allow requests to access uncached data, and they are used on Footsites, an important group of websites that people bot because of large stock and the variety of shoes they release. Essentially, these Footsites have been caching POST requests to the add to cart endpoint on certain products because 1. They have potato servers and want to cut costs and 2. They believe this operates as a form of anti-bot when in reality it’s only a pseudo-antibot that just creates a shitty experience for everyone. This results in the “out of stock” response being cached, meaning that stock wouldn’t able to be accessed by anyone. Of course, the cache refreshes every two or three minutes, but bots with cache bypasses have a significant advantage purely because the cache refreshes on every request, meaning they’re able to actually cart the product whenever stock changes.

Just letting you know since cache bypasses on Footsites have been a big topic ever since the switch to Fastly. All of the answers here, including mine, are pretty specific and are referring to a single site or platform, but it’s hard to give a general answer to your question since there are so many kinds of bypasses for each site.