One of the most in-demand restaurants in Tel Aviv is OCD - listed in almost every list of the best restaurants in Israel. It seats 38 people a night, and it's open only four nights a week - so the supply of seats at the restaurant is far below the demand. There's usually a very long reservation list - many of the reviews on Google, beyond just raving about the food and experience, mention how the reviewer had to reserve a place months in advance.

My girlfriend and I are really into food and restaurants, and after hearing all the hype and endless recommendations - we wanted to place a reservation. It seems that at some point down the line, OCD started using a reservation system wherein you can only reserve a month in advance - there's a preannounced date and time when the slots for the next month open up.

I missed the October date for November reservations by sheer incompetence forgetfulness, so this time around I placed the November date for December reservations in my calendar and made sure to be available:

November date for December reservations

This is a short blog post about basic HTTP interception tricks I used to be able to place the reservation - though the tricks aren't too sophisticated, I think it's a nice demonstration of how powerful HTTP interception can be in our modern society.


OCD, like many restaurants in Israel, uses a third-party SaaS called Ontopo for managing its reservations.

Ontopo is where we can see that no seats are available for November:

No available seats for November

So on November 19th, 2024, 10:30 AM, I was in front of my laptop, refreshing the Ontopo reservation page, waiting for the list of dates to include December dates. But for more than an hour afterwards, the list did not update:

Only November dates

This was pretty annoying, because I didn't want to miss another month of reservations, but I had work to do and didn't want to hang around refreshing the page. My spider sense suggested that perhaps the dates themselves were enabled, but for whatever reason populating the list of dates wasn't yet working.

I followed this hunch by opening up Chrome's developer tools and checking what API was called when checking for a date's availability:

Availability API

In the image we can see that an availability_search API is called, which returns the "No available seats" message we see. I imported the API call into Postman to play around with it:

Imported Postman request

And then I tried modifying the date field with a December date to see what results I'd get:

Modified Postman request

And the API returned available seats!! This confirmed my hunch that the dates were already available. I tried checking January and February dates, but they were all unavailable - which strengthens the hypothesis.

After briefly considering the morality of working around a malfunctioning system to make a reservation, I decided to go ahead and intercept the availability_search API call that Ontopo makes to work with my desired December date. There are many ways to achieve this, but I went with the Requestly Chrome extension - I configured it to intercept all outgoing availability requests to replace the date with the December date:

Requestly configuration

And we can see this working here:

Requestly modified request

Even though the selected date in the GUI is "Today" (i.e. November 19th), the returned results are for December 4th! You might notice that the results are in Hebrew - because I actually used the body of an API request I made from the Hebrew Ontopo website (you can see locale=he in the Requestly configuration).

So, excitedly, I clicked on the button to make the reservation, but was a bit dejected to see:

Choice no longer available

For a second I was worried that the validation scheme was more sophisticated than I thought, but my worries were unfounded - it turns out that the page makes another availability_search call, but with an availability_id hash in the body that needs to be equal to the availability_id returned in the first call. I refreshed the page and re-intercepted the first outgoing request, then reconfigured Requestly to populate the availability_id field with the received value, and then clicked the button to get:

OCD waiting page

This was a bit surprising, it seemed like I was placed in a wait queue for making the reservation. Was I competing with other people going through the same process? Then I realized I was probably competing with myself - my experimental API calls probably placed several "potential" reservations in the system. I looked at the requests of the page to see what was going on:

Checkout queue API 1

There was a repeated API call that returned my place in the queue, and after a couple of minutes it went down from 3 to 2:

Checkout queue API 2

I considered trying to do some HTTP tricks here too, but it seemed safer to just wait five minutes until it was my turn in the queue, and:

Reservation success

Woohoo! This was the page I wanted to get to - placing a reservation for December 4th.

From here everything was smooth sailing, and I was finally able to place a reservation for two weeks from now:

Booking confirmation


Thirty minutes after I placed the booking, I checked again and the December dates still didn't appear in the Ontopo site. I checked again forty minutes after that, and the dates did appear - but everything was already booked.

My girlfriend was so impressed she let me off the hook for forgetting to wash my dishes yesterday - though she did get upset later on in the day when I yelled "HTTP interception" to interrupt her real-life conversation. I hope this goes to demonstrate just how powerful HTTP interceptions can be.