Do Reservation Bots Actually Work?
George Yates · Founder, SeatSwiper · Updated September 24, 2026
It books in your name the moment a table opens or someone cancels. First booking free.
Try it on one tableSearch GitHub for a Resy booking bot and you will find dozens of repositories, several with recent commits and real users in the issues tab. They are not vaporware. A competent one can complete a booking in the time it takes a person to unlock a phone. The interesting question is not whether the code runs, it is what running it actually buys you once you account for the maintenance and the traffic it generates. Last verified 24 September 2026.
How does a drop-time sniper work mechanically?
The published scripts converge on the same shape because the constraint is the same. Before the release hour, the script authenticates and caches a session so no login happens on the critical path. It resolves the venue to an internal identifier and pre-fetches the configuration for the date it wants, so that at the moment of release it already knows which slot token it intends to claim. Then it loops, hitting the availability endpoint on a tight interval, and the instant a slot appears it posts the booking payload. The entire advantage lives in the last two steps: a human sees a rendered page a second or two after the data existed, while the script is already holding the confirmation. The release conventions themselves are in the 10am drop explained.
It books in your name the moment a table opens. First booking free.
Try it on one tableWhy is the polling interval the part that gets you caught?
Because it is the one behavior that is loud, continuous and trivially measurable from the server side. CNN Business reported on 23 September 2026 that an AI assistant pointed at a hard New York room was generating roughly 200 API requests an hour around the clock and polling roughly every 0.4 seconds near the drop, and that the diner’s Resy account was deactivated, then later reinstated. Use that as the worked example, because the tradeoff it illustrates is inescapable. A slower interval misses the slot. A faster interval is the signature. There is no configuration value that is both fast enough to win a synchronized release and quiet enough to be indistinguishable from a person. The full incident write-up is in the Resy deactivation CNN reported.
What breaks, and how often?
These scripts talk to internal endpoints that were never published for third parties and carry no compatibility promise. Concretely, the things that change underneath you:
- Authentication flows, which are exactly what a platform hardens first.
- Endpoint paths and payload field names, renamed without notice or changelog.
- Required headers and client identifiers, added specifically to filter unknown clients.
- Slot token formats, which turn a working booking call into a silent 400.
The failure mode is what makes this expensive rather than the frequency. A broken script rarely announces itself. It keeps looping, keeps logging, and you discover the problem on the evening you expected a table and do not have one. Budget for reading someone else’s code under time pressure, on the day the release happens, roughly whenever a platform ships an update.
Do they work better on releases or on cancellations?
Cancellations, by a wide margin, and it is not close. A scheduled release is a synchronized race with many entrants and a fixed, small number of seats; being fast improves your odds but the arithmetic is still brutal. A cancellation is the opposite situation: a table returns at 11:40pm on a Tuesday, or at 2pm on the day, and almost nobody is watching. Continuous attention wins those by default. The catch for a self-hosted script is that continuous attention is precisely the expensive, detectable, always-on mode, and you are paying for a virtual server to sustain it. The rhythm of when tables come back is in restaurant cancellation policies, and the category map of tools is in Resy sniper apps and reservation bots.
So what is the honest verdict?
A self-hosted bot works if you enjoy the maintenance and accept the account exposure as the price of admission. It is a genuinely reasonable hobby project. It is a poor plan for an anniversary. The three real costs are your time, a server that never sleeps, and the credential handling described in should you give an AI agent your Resy login. Nothing in the category, mine included, changes the underlying scarcity: one seat, many watchers, one winner.
What a hosted watch does differently
SeatSwiper is the managed version of the cancellation half of this, and I would rather describe it in the same technical terms than in adjectives. You describe the restaurant, the dates, the party size and the time range; the watch runs continuously on infrastructure that is not your laptop; when a seat appears it books on your own Resy, SevenRooms or OpenTable account, in your name. When a platform changes something underneath, fixing it is my problem rather than your Friday. What it is not: approved by any platform, immune to a platform action, or a guarantee of a table. It covers those three platforms and not Tock or restaurant-run booking pages. On cost: nothing for a first successful booking, then $5 flat and only when it lands one, with no subscription. Arming a cancellation watch costs $1, and that dollar is spent when the watch starts whether or not a seat ever opens, free first booking or not; if the watch wins, the usual $5 follows. If none of that is worth $5 to you, the repositories are free and the README files are usually good.
FAQ
Do open-source Resy bots still work in 2026?
Many do, and several repositories carry recent commits and active issue threads. The catch is that they call internal endpoints carrying no compatibility promise. Authentication flows, payload field names and required headers change without notice, and a broken script usually keeps looping silently rather than telling you it has stopped booking anything.
How fast does a reservation bot have to poll?
Fast enough that the tradeoff becomes the whole problem. CNN Business reported on 23 September 2026 that one AI assistant polled roughly every 0.4 seconds near a drop and made around 200 requests an hour overall. Anything slower misses slots; anything faster is precisely the pattern platforms measure and act on.
Are bots better at scheduled drops or at cancellations?
Cancellations, decisively. A drop is a synchronized race with many entrants and few seats, so speed improves your odds without changing the arithmetic. A cancellation surfaces at 11:40pm on a Tuesday when almost nobody is watching, and continuous attention wins those close to by default. Sustaining that attention is what costs you a server.
What does running a reservation bot actually cost?
Three things: an always-on virtual server, your own hours spent reading and repairing someone else’s code on the day a platform ships a change, and the account exposure from storing credentials while generating continuous traffic. The code itself is free. The maintenance is the price, and it arrives at inconvenient moments.
Does a hosted watch avoid these problems?
It moves the maintenance to someone else and runs the watch on infrastructure that is not your laptop, which is the practical difference. It does not make a tool approved by any platform, immune to a platform action, or able to guarantee a seat. SeatSwiper covers Resy, SevenRooms and OpenTable, and not Tock.