How to Scrape OpenTable Data (Availability and Reviews)
Scrape OpenTable data that survives the next deploy: read ratings and reviews from each restaurant's JSON-LD, then pull availability from the GraphQL API.
To scrape OpenTable data that survives OpenTable's next deploy, split the job into two problems that behave nothing alike: the static facts and the live availability. Ratings, review counts, cuisine, price band, and address all sit in a schema.org JSON-LD block on every restaurant page, so those parse cleanly and almost never move. Reservation time slots are the hard part. OpenTable loads them from a GraphQL endpoint (/dapi/fe/gql) guarded by a CSRF token and a persisted-query hash it rotates between releases, so they are not in the initial HTML at all. This guide walks the full pipeline for public OpenTable data: searching a metro, reading ratings from JSON-LD, pulling live availability the durable way, and paging through verified-diner reviews without tripping the bot wall. Every request runs through SparkProxy's Scraping API, so browser rendering and residential IP rotation are request parameters instead of infrastructure you babysit.
Is scraping OpenTable data legal?
OpenTable restaurant profiles, ratings, and reviews are public: you can open a page and read all of it without logging in. That answers the access question, not the permission question, and the two are separate. Get the framing straight before you write code.
In the United States, the Ninth Circuit's decision in hiQ Labs v. LinkedIn (2022) held that scraping data that is publicly accessible, meaning no login and no authentication wall, generally does not violate the Computer Fraud and Abuse Act. That ruling is about unauthorized access, not a blanket license to copy. OpenTable's Terms of Use separately prohibit automated collection, and its robots.txt restricts crawlers on many paths. So scraping OpenTable can breach its terms and stated crawl policy even where it clears the CFAA bar. Different questions, different answers.
There is no public data API to fall back on. OpenTable retired its old affiliate and partner data API years ago, and what remains is a booking integration restricted to OpenTable's restaurant partners, not an open feed an outside analyst can request. That gap is exactly why people scrape the public pages for research, market analysis, and competitive tracking, and it is the gray-area space this guide operates in.
Guardrails that keep an OpenTable project defensible:
- Collect public data only: restaurant name, cuisine, rating, review count, price band, address, and published review text. Nothing behind a login or tied to a diner's account.
- Treat reviews as personal data. An OpenTable review ties a real diner's name to an opinion and a dining date, which is personal data under GDPR and CCPA. If you do not need reviewer identities, do not store them.
- Never turn availability scraping into a booking. Reading the published slot times on a page is fine. Clicking through to reserve or hold a slot, even for a second, removes that table from real diners and can trigger no-show penalties for the restaurant and abuse enforcement against you. Read slots; never book them.
- Honor
robots.txt, rate-limit hard, and back off on errors so you never degrade the service for the people actually trying to book dinner.
This is engineering guidance, not legal advice. If the data feeds a commercial product, run the plan past a lawyer first.
What data you can extract (fields reference)
An OpenTable restaurant page carries most of what you want inside one embedded JSON-LD block, plus availability that lives somewhere else entirely. The search results page is thinner: it is a list of cards linking to restaurant profiles, so the durable pattern is to harvest restaurant slugs from search, then follow each one for the full record. Here is the reference set worth pulling, with the stable way to get each field as of mid-2026.
| Field | Where it lives | How to get it | Notes |
|---|---|---|---|
| Restaurant name | JSON-LD `name`; page `h1` | Parse the `application/ld+json` block | JSON-LD is the most stable source |
| Restaurant slug | canonical URL `/r/ | `link[rel="canonical"]` or the `/r/` href | Your stable per-restaurant identifier |
| Rating | JSON-LD `aggregateRating.ratingValue` | float, 1.0 to 5.0 | OpenTable rates on a 5-point scale |
| Review count | JSON-LD `aggregateRating.reviewCount` | integer | Matches the "N reviews" on the page |
| Cuisine | JSON-LD `servesCuisine` | e.g. "Italian", "Steakhouse" | Sometimes a list |
| Price band | JSON-LD `priceRange` | `$` to `$$$$` | OpenTable maps this to its own tiers |
| Address | JSON-LD `address` (PostalAddress) | street, locality, region, postal code | Cleanly split into fields |
| Phone | JSON-LD `telephone` | formatted string | Not always present |
| Availability (time slots) | GraphQL `/dapi/fe/gql` | render the page, then read slot buttons | NOT in the JSON-LD or initial HTML |
| Reviews (sample) | JSON-LD `review[]` | first few reviews | Full set via `?page=` pagination |
Two rows explain the whole shape of this job. The rating, review count, cuisine, price, and address are handed to you already parsed inside the