The table was gone in four seconds, and it was never for sale

Reservations at in demand restaurants are released on a schedule, and software that never intended to eat anything takes them at the instant of release. New York made the resale illegal in 2025. That was the right instinct aimed at the wrong end of the problem, because the resale is the symptom and the booking is the disease.

Somebody wants to take their partner somewhere good for an anniversary. The restaurant releases tables thirty days ahead at ten in the morning, which is a system designed to be fair, and they have set an alarm, which is a thing adults now do. At 09:59 they are on the page with the date selected. At 10:00:00 they refresh.

At 10:00:04 there is nothing. Not one table at any time on any of the three days they would accept. The calendar looks exactly as it did the day before, as though the release never happened.

That evening, idly, they find one of those tables listed on a secondary marketplace. Same restaurant, same night, eight fifteen, two covers. Two hundred and fifty dollars, and the two hundred and fifty dollars does not buy dinner. Dinner is extra. It buys the right to sit down.

Here is the detail worth pausing on, because it is the whole story in one line. The restaurant charged nothing for that table. It deliberately charged nothing, because it wanted to allocate its scarce evenings to people who wanted to come, not to people with the most money. Somebody else has now charged two hundred and fifty dollars for it and the restaurant will not see a cent, and if the buyer does not turn up the restaurant eats the loss.

Why can I not get a reservation at popular restaurants?

Because at the moment of release you are competing against software, and you lose in a way that is not close.

The mechanics are unglamorous. A reservation platform publishes inventory on a predictable schedule, thirty days out at ten, or the first of the month, or some similar rule that exists to be fair and has the side effect of being an appointment an automated client can also keep. The operator holds many accounts, warmed with plausible histories and different payment instruments. At the release instant, requests fire in parallel, faster than a person can select a time and confirm.

You are not slow. Human reaction time to a visual change is somewhere around a quarter of a second before you have moved a finger, and then you have to read a grid, choose, and confirm. Software that already knows what it wants does not read the grid. The gap is not one of effort or preparation, and no amount of setting your alarm earlier closes it.

The inventory then moves to a secondary market where it is priced at what the scarcity is actually worth. This is straightforward arbitrage. Somebody produced a valuable thing and gave it away for free, and a market exists to capture the difference between the free price and the real one.

Is reselling restaurant reservations illegal?

In New York, largely yes, and that is recent.

The Restaurant Reservation Anti Piracy Act was signed in December 2024 and took effect on 17 February 2025. It restricts third party services from listing, selling or arranging the sale of a restaurant's reservations without a written agreement with the restaurant, with civil penalties reported at up to one thousand dollars per violation per day. The framing is worth noticing: the legislature treated the reservation as something belonging to the restaurant, which is not obvious and is arguably the most interesting thing about the statute.

There is a clear precedent in ticketing. The Better Online Ticket Sales Act of 2016, universally called the BOTS Act, made it unlawful to circumvent access controls on ticket sellers' systems in order to buy tickets in bulk, and to resell tickets obtained that way. The Federal Trade Commission enforces it.

Both laws share a structure and therefore a limitation. They regulate what happens to the inventory after it has been taken. The BOTS Act does reach the circumvention itself, which is more than the New York statute attempts, but enforcement is retrospective in both cases: someone must notice, gather evidence, and bring an action, while the software runs every morning at ten.

The gap the statutes leave open

Consider an operator who books prime tables automatically and does not resell them at all. Perhaps they are a concierge service that includes tables in a membership. Perhaps they simply take a hundred tables and cancel ninety at the last minute. Perhaps they are one very determined person with a script and no commercial motive whatsoever.

None of that is resale, so the New York statute does not reach it, and the restaurant experiences exactly the same loss. That is not a drafting failure. It is what happens when you regulate a market that forms downstream of an allocation problem, rather than the allocation.

Why do restaurants care if someone resells a free table?

Outsiders assume the restaurant is indifferent, or even flattered. It is full either way, the argument goes, so what does it matter who is sitting there.

That argument misunderstands what a reservation is. A reservation is a promise in both directions. The diner promises to arrive, and against that promise the restaurant commits real money before anyone walks in.

What the restaurant has already spent

A kitchen builds its order against the book. Proteins are ordered days ahead, produce is bought that morning, prep begins in the afternoon, and the number of people on the floor that night is set by the covers on the sheet. A restaurant operating on the thin margins normal in the industry has converted a substantial fraction of that evening's expected revenue into perishable inventory and scheduled labour before the first guest arrives.

Now the resold table no shows, which happens more often than an ordinary booking because the person who bought it at a markup is a different kind of customer with a different attachment to the plan, and the buyer may have purchased several nights speculatively. The restaurant has the cost and not the revenue, the table sits empty through the prime window, and the regular who called and was told there was nothing available went somewhere else.

The part that stings

The restaurant chose not to charge for that table. Plenty of restaurants could auction their Saturday eight o'clock slots and do not, because they would rather be a place where a person who reads about them can get in than a place where a seat goes to the highest bidder. That is a positioning decision, made deliberately, at a cost.

Scalping overrides that decision without asking. The table is auctioned after all, the money goes to a third party, and the restaurant keeps the reputational cost of being impossible to book while somebody else banks the scarcity it created. This is why restaurateurs supported the New York bill with more energy than most trade groups bring to most legislation.

Why do CAPTCHAs, queues and card holds not stop this?

Each of these is a real control and each fails in an instructive way.

CAPTCHAs ask a question a computer is supposed to find hard. That premise has not survived. Solving services accept an image and return an answer through an API for a fraction of a cent, using a mix of models and low paid human workers, and an operator budgets for it as a per request cost. Meanwhile the honest diner does the puzzle three times because the first two failed, at ten in the morning, while the inventory disappears.

Virtual queues randomise arrival rather than rewarding speed, which is genuinely fairer and is the best of the current options. But a queue allocates by lottery among entrants, and an operator holding four hundred accounts holds four hundred lottery tickets. Randomisation without a bound on entries per person converts a race into a raffle that the same party still wins.

Card holds and deposits attach a cost to the booking, which does deter the casual multi booker. Against a commercial operator they fail twice. Cards are cheap to obtain in volume through virtual card services, so the hold is a working capital cost rather than a barrier. And the deposit lands hardest on exactly the people the restaurant wanted to protect, because a family for whom fifty dollars per head held against a table is a real consideration is not the party you were trying to price out.

Account limits and phone verification assume identifiers are scarce. Email addresses are free, phone numbers are cheap in bulk, and an operator running hundreds of accounts treats both as consumables. Every control here is defending an assumption about cost that stopped being true.

What all four share is that they measure something adjacent to the thing that matters. They ask whether this request looks automated, whether this account looks new, whether this card looks valid. None of them asks the only question the restaurant actually cares about: is there one distinct person behind this booking, and will that person be at the table.

What do tables, tickets, sneakers and visa appointments have in common?

Once you see the shape you cannot stop seeing it, and it is worth naming because the same control fits all of them.

Take any scarce thing, allocate it free or below its market value, publish the moment of release, and permit automated participation. An arbitrage appears immediately, and its size is the gap between the allocated price and the real one. Restaurants are a mild case because the numbers are small. Concert tickets are the same mechanism with a great deal more money attached, which is why it produced federal legislation and congressional hearings, and we wrote about the consumer end of that in the bot tax.

Limited sneaker releases are the same. Public appointment slots for visas and driving tests are the same, and worse, because the underlying good is a government service that was never supposed to have a price at all. Vaccine appointments were the same during the periods when supply was constrained. Queue positions of every kind are the same.

The last two rows are why this piece sits next to denial of wallet and one human, one welcome offer. Different industries, different vocabularies, same missing primitive: nothing binds an allocation to a person, so it is taken by whoever automates best.

What would one human, one reservation look like?

The requirement is narrower than it first appears. The restaurant does not want to know who you are. It has never wanted to know who you are. It wants two things: that this booking belongs to a distinct person, and that the person who booked is the person who shows up.

At booking

Before a prime slot is confirmed, the platform asks the device for a presence proof. The check runs locally and produces a one way key scoped to that platform, plus a signed receipt. No image, no document, no name beyond whatever the platform already collects for the booking itself.

{
  "type": "booking.human",
  "context": "resy.example",        // scoped key: not portable to other services
  "human_key": "b7d1...9a04",        // one-way; collides only with itself
  "slot": "2026-11-14T20:15",
  "party_size": 2,
  "issued_at": "2026-10-15T10:00:01Z"
}
// Ed25519 signed. Verifies offline against a published key.
// The platform learns: this is one distinct person. Nothing else.

The uniqueness rule is applied where it is needed rather than everywhere. One prime booking per person per night is a defensible policy. Four hundred accounts collapse to however many distinct humans the operator can actually put behind them, which is the number that decides whether the business works. We describe the general form of this in one human, many accounts.

At the door

Booking side proof alone leaves the resale market intact, because a proven human can still sell their table. So for the slots that matter, the check in re-establishes the same person.

// host stand, prime slot
const ok = await manav.attest({ context: "resy.example", mode: "glance" });
if (!ok.matches(booking.humanKey)) {
   // not a rejection: the table is honoured, the booking is flagged
   flagForReview(booking);          // repeated mismatches identify a farm
}

Note that the mismatch path does not turn anyone away. A restaurant that refuses a table to a confused guest at eight fifteen on a Saturday has traded a small fraud problem for a large hospitality one. The value is in the pattern across bookings, not in any single door.

Reservations suit this unusually well, and it is worth saying why, because the same control would be disproportionate elsewhere. The diner is going to physically appear in a specific place at a specific time anyway. A presence check at the door is not an imposition invented for security. It is a formalisation of something that was already going to happen.

The legitimate agent booking

Here is where this stops being about restaurants and starts being about the next two years.

Assistants that book on your behalf are being marketed now, and they are a genuinely good use of the technology. Booking a table is tedious, and a system that does it while you work is straightforward value. Which means "this booking was made by software" is about to stop being a useful signal, because a large share of honest bookings will be made by software.

The distinction that survives is not human versus automated. It is authorised versus not. An assistant booking for a person who will attend should carry a delegation receipt: a scoped, revocable grant signed by that human, naming the action and its limits, which the platform verifies at booking time.

{
  "type": "delegation",
  "delegator_key": "b7d1...9a04",       // the human who will eat
  "delegate_key":  "agent:6f2b...",     // the assistant
  "scope": { "actions": ["reservation.book"], "max_bookings": 1 },
  "notBefore": "2026-10-15T00:00:00Z",
  "notAfter":  "2026-10-22T00:00:00Z",
  "revocationId": "r-8812"
}

Now the platform can allow agent bookings and still cap them per human, because the chain terminates at a person. A scalper's software has no such chain, or has one that traces to a human already at their limit. The related liability question, of who answers when an agent transacts, is covered in my agent did it.

Honest limits

This requires the booking platforms to adopt it. A restaurant cannot deploy it alone. The inventory lives on Resy, OpenTable, Tock or SevenRooms, and the control has to sit where the booking is made. That is a business development problem, not a technical one, and it is the real obstacle.

An operator with real humans still gets through. If you pay two hundred people to enrol and book, you have two hundred bookings. The claim is not impossibility. It is that the cost per booking stops being a fraction of a cent and becomes the cost of a person's cooperation, and at that price most of this trade is not worth running.

It does nothing about the restaurant's own choices. Some scarcity is manufactured, some inventory is held back for walk ins or regulars or press, and some places are hard to book because they are small and popular. None of that is a bot problem and no identity technology should pretend to address it.

Check in proof adds a step at the busiest moment of the night. A host stand at eight on a Saturday is not a place to introduce anything slow. If it is not close to instantaneous, it will not be used, and it should not be used on ordinary bookings at all.

Groups and gifts are genuinely awkward. One person books for six and does not attend. A table is a legitimate gift. Any implementation needs a clean path for both, and a design that treats every transfer as fraud will be routed around by honest people within a week.

What to do this week

If you run a reservation or ticketing platform:

1. Measure the interval between release and first confirmation, and the distribution of confirmations in the first ten seconds. If the curve spikes at under two seconds you already know what you are dealing with.
2. Count distinct payment instruments per account cluster and accounts per device family. You will find the farms before you find any individual bot.
3. Instrument no show rates by booking age and by how quickly after release the booking was made. Resold inventory behaves differently and the difference is measurable.
4. Decide your policy on assistant bookings now, before it is forced, and decide it as an authorisation question rather than a detection one.
5. Pilot a uniqueness proof on prime slots only. It is the smallest change with a measurable result and it does not touch the ninety percent of inventory nobody is fighting over.

If you run a restaurant:

1. Ask your platform what it does about automated booking, and ask for numbers rather than assurances.
2. Hold back a portion of prime inventory for same day release. It is a partial answer and it is available immediately.
3. If you are in a jurisdiction with a resale statute, know that reporting a listing is a real remedy and takes minutes.

There is a working demonstration of a human bound booking gate at /labs/ticket-bots/, and the integration shape is documented in the docs.

Frequently asked questions

Why can I not get a reservation at popular restaurants? Because prime tables are frequently taken within seconds of release by automated booking software running many accounts, then resold on secondary marketplaces. The release schedule that exists to make allocation fair is also a predictable appointment that a script can keep, and no amount of human speed closes the gap.

Is reselling restaurant reservations illegal? In New York, largely. The Restaurant Reservation Anti Piracy Act took effect on 17 February 2025 and restricts third party platforms from listing or selling a restaurant's reservations without a written agreement with that restaurant, with civil penalties reported at up to one thousand dollars per violation per day. Other jurisdictions have not generally followed yet.

Why do restaurants object if the table is resold rather than wasted? Because a reservation is a commitment the restaurant spends money against. Food is ordered and staff are rostered before anyone arrives. Resold tables no show more often, the restaurant keeps the cost without the revenue, and the resale money goes to a third party while the restaurant keeps the reputation for being impossible to book.

Can an AI agent book a restaurant for me legitimately? It should be able to, and the distinction that matters is not human versus automated but authorised versus not. An assistant acting for a person who will attend can carry a scoped, revocable delegation signed by that person, which lets a platform allow agent bookings while still capping them per human.

Do CAPTCHAs stop reservation bots? No. Solving services return answers through an API for a fraction of a cent, so a CAPTCHA is a small per request cost to an operator and a genuine obstacle to an honest diner who fails it twice while the inventory disappears.

Would this require diners to hand over identity documents? No. The design described here proves that a distinct person is behind a booking using a one way key derived on the device, scoped to that platform. No document, no photograph and no biometric record is transmitted or stored, and the key cannot be correlated with any other service.

Sources

1. New York State Senate, legislation index for the Restaurant Reservation Anti Piracy Act, signed December 2024 and effective 17 February 2025: nysenate.gov/legislation. Penalty figures as reported in contemporaneous coverage of the statute.
2. Better Online Ticket Sales Act of 2016, text and legislative record: congress.gov.
3. Federal Trade Commission, enforcement of the BOTS Act and guidance for ticket sellers: ftc.gov.
4. Office of the Governor of New York, announcements on restaurant reservation legislation: governor.ny.gov.
5. National Restaurant Association, industry material on operating margins and no show costs: restaurant.org.

The restaurant decided its Saturday table should cost nothing. Somebody sold it for two hundred and fifty dollars, and the only party who lost money was the one who made the decision.