Restaurant Booking API for AI Agents: 2026 Platform Audit

Call Eva at +1 (929) 632-1061 to hear an AI take a restaurant booking on the phone (Eva, the demo host at "Osteria da Luca"). No signup, no form. To scope a real integration, use our contact page.

If you are building an AI agent that books restaurant tables, the question is not which AI product is best. It is which reservation platform will let your code write a booking at all. The answer, as of 5 September 2026, is uneven and mostly undocumented in public. OpenTable publishes an API whose own name is the Voice AI API, with a create-reservation endpoint and a partner-approval process that includes a quality-assurance pass specifically for voice AI partners. Tock rules the whole thing out in its own words: "No, reservation creations and cancellations must be done through the Tock dashboard." Resy publishes no developer documentation anywhere, and SevenRooms moved its API documentation behind a login, so its surface cannot be inspected. This page audits ten platforms against one test: can an approved third-party system read availability and write a reservation, and what does the vendor's own documentation say?

Which restaurant booking platforms expose a reservation-create API?

Here is the register: twelve documented surfaces across ten platforms. "Public dev docs" means documentation reachable without a login on 5 September 2026, not "an API exists somewhere". Every cell traces to the vendor's own page, cited in the section below it. The rows are ordered roughly by network size, and the pattern that falls out is the page's thesis: the bigger the network, the harder the gate.

Two platforms named in most restaurant AI roundups are deliberately absent. No public API documentation was located for Tablein or Tableo on 5 September 2026, and asserting a negative on a thin search would be the same mistake this page exists to correct, so both are omitted rather than marked "no". For the vendor-side comparison of AI products that sit in front of these platforms, see our separate roundup of AI systems for restaurant reservations. This page deliberately does not rank AI vendors; it audits the platforms they have to write into.

Does OpenTable have an API built for voice AI agents?

Yes, and OpenTable named it after the use case. The published name in OpenTable's own documentation is "In House Booking API (aka Voice AI API)". OpenTable describes it as follows: "The In-House Booking API facilitates the seamless booking of reservations directly into a restaurant's inventory, encompassing both In-House and Online availability. This powerful API is specifically engineered to support a range of reservation management functionalities, particularly for Voice AI driven reservation systems." The same section adds: "Primarily developed to power Voice AI reservation systems, this API is designed for efficiency and integration with advanced conversational interfaces. Its architecture supports automated and real-time interactions, crucial for voice-based booking experiences." (source: OpenTable API Documentation, fetched 2026-09-05)

The approval gate is a real process, not a form

OpenTable states plainly: "To obtain access to OpenTable APIs, it is requisite to register and secure approval as an integration partner." What follows is a review: "Upon submission, your application will undergo a comprehensive review by our partnerships team, and you will be notified upon the completion of this review process. Once approved, you will be granted access to a Sandbox environment to try out the integration." Production access is contractual: "Access to our APIs is subject to approval and requires the execution of a formal agreement outlining the terms of use." And not every approved partner gets every API: "Not all APIs are available for every type of partnership. Eligibility for specific APIs is determined based on the nature of the partnership, use case, and technical feasibility. Additionally, the cost of access may vary depending on the API or the selected API tier." (source: OpenTable, Getting Started and Environments, fetched 2026-09-05)

For voice specifically there is an extra step that no roundup mentions: "This Integration is available only to approved partners that have signed the applicable paperwork and agreed to the terms and conditions. Also note before a Voice AI partner is approved, there will be a Quality Assurance process to ensure the integration is successful." In other words, OpenTable listens to the agent before it goes live. OpenTable documents the programme; it does not publish a list of approved participants, so no third party's claim to hold this partnership is verifiable from OpenTable's own pages.

OpenTable also documents a second write-capable API, the Online Booking API (Consumer API v2), which "offers a wide array of capabilities, providing restaurants with the ability to not only search for available tables in real-time across single or multiple restaurant locations but also to create, modify, and cancel reservations directly within their own website or application." Its onboarding is the same shape: "During the onboarding process, you will only have access to our pre-production test restaurants. You will be given access to your production restaurants upon certification."

What can OpenTable's In-House Booking API not do?

This is the part a buyer needs and no comparison page carries. OpenTable publishes a "Known limitations" list for the voice AI booking path. Verbatim, as separate bullets on that page:

• "Voice AI cannot pass the 2% OpenTable service charge on to guests."
• "A diner profile is created and identified based on phone number, first and last name."
• "Requires a mobile number capable of receiving SMS. Landline numbers are not supported."
• "Ticketed experiences are not supported"
• "Experiences cannot be cancelled or modified through this API"

Read the third bullet twice. A diner calling from a landline cannot be booked through this path, because the flow requires a mobile number that can receive an SMS. That is a genuine operational constraint on an inbound phone agent, and it has to be designed around: the agent needs a fallback for the caller who has no mobile, whether that is a message to the host stand or a human transfer. The 2% service charge line is the only OpenTable fee figure quoted here, it is OpenTable's own wording, and it should be re-verified at docs.opentable.com as of 5 September 2026 before anyone relies on it commercially.

One more detail worth knowing before a restaurant asks "how will I tell which bookings the AI took?" OpenTable tags them: "API-originated reservations are identified with an 'phone/in-housed' tag in reservation history details. The Reservation Report displays 'phone/in-house' as the booking source for API reservations, as opposed to 'Phone/In-House' for standard bookings." The reporting distinction exists, which means the restaurant can audit the agent's work rather than take it on trust.

Can an API create a reservation in Tock?

No. This is the clearest negative in the whole audit, and it comes from Tock's own support documentation, in an article last updated 22 July 2026. The question and answer, verbatim: "Is it possible to create or cancel a reservation using the API? No, reservation creations and cancellations must be done through the Tock dashboard." A second answer on the same page narrows it further: "What data can be updated in Tock using an API? Tock only allows creation and updating of basic guest information via the Guest Ingest API. Reservation data cannot be manipulated using an API." (source: Tock, API FAQ, fetched 2026-09-05)

The read side does not rescue it either. Tock's published API surface is four things: a "Data Exports API: Twice daily export of all historical reservation and guest data", a "Guest Profile Ingest API: Add and update guest data in Tock, including guest profile tags", a "Real-time Guest Profile Webhook", and a "Real-time Reservation Webhook". The export is not live data: "The export files are generated twice daily, with each file containing data that is updated as of 12 hours prior." And availability is simply not available: "Is it possible to pull available bookings for a restaurant (unbooked reservations)? Not at this time, but Tock is working towards adding this functionality in the future."

Access, where it exists, is plan-gated: "Do I qualify for API and Webhook access? Premium plans are eligible to receive API/ Webhook access." And the key is issued by hand: "Request your API key by emailing api-integration@resy.com from an email address listed as an Account Owner on the business' Tock Dashboard Team page." The same page routes plan questions to hospitality@resy.com. Tock's own API support runs through Resy addresses; that is what the page says, and no more should be read into it here. Tock's own documentation host, meanwhile, publishes nothing: api.exploretock.com/docs returns a 108-byte page reading "Docs coming soon."

Where is Resy's API documentation?

There is none in public. Resy publishes no developer portal. On 5 September 2026 a DNS and HTTPS probe of the five obvious candidate hostnames - developer.resy.com, developers.resy.com, docs.resy.com, api-docs.resy.com and partners.resy.com - returned NXDOMAIN on all five, with no connection established to any of them. That is a finding a reader can re-run in one command, and it is stated here as an observation rather than as a claim about Resy's intentions.

The only Resy-owned statement about an API is a single sentence of marketing copy on its hospitality-groups page: "With an open API, webhooks, and integrations, Resy serves up your data—when, where, and how you need it." (source: Resy, Solutions for Hospitality Groups, fetched 2026-09-05) The page carries no link to documentation and no access instructions; its only call to action is "Book a demo". Resy's integrations page is similar - it names partner categories (POS and event systems, reservations and discovery, CRM and guest management, data and analytics, winery and e-commerce) and no developer surface at all.

Does SevenRooms publish API documentation without a login?

No. As of 5 September 2026 the entire public surface of api-docs.sevenrooms.com is one notice: "Effective February 26, we have moved to individually provisioned accounts for access to our API documentation." It directs new integrators to a partnerships form - "If you are a new user interested in integrating with our API, please fill out our partnerships form" - and existing ones to an email address for restored access. The notice does not state a year for "February 26", and none is supplied here. No endpoint, method, auth model or schema is visible. Two other plausible hostnames and one likely path all return HTTP 404.

That is the finding, and it is worth stating flatly because the alternative is worse. Third-party pages list specific SevenRooms endpoint names. None of them could be verified against SevenRooms' own documentation, because the documentation requires a login. A confident wrong claim about an API is more damaging than an admission that the surface could not be inspected.

What SevenRooms does say, in the FAQ on its own integrations page: "Yes, we have two restaurant APIs to give our users flexible access to their data. We offer our customers access to our Reservations API at a monthly cost. We only approve requests that come directly from our customers. SevenRooms customers can leverage the Reservations API to build custom applications on top of their guest data or integrate with approved third parties." And on the second one: "Our Concierge API allows SevenRooms concierge and booking channel partners to offer real-time reservation availability and booking capabilities directly to guests or corporate concierge providers. Depending on the partnership, there may be a cost to integrate with our Concierge API." (source: SevenRooms, Restaurant API and Integrations, fetched 2026-09-05) That is marketing copy, not documentation: it is good evidence of the commercial posture and no evidence at all of the technical surface. The "monthly cost" is unquantified on that page; verify it with SevenRooms directly, as of 5 September 2026.

Two practical consequences follow from the wording. First, the request has to come from the restaurant, not from you: "We only approve requests that come directly from our customers." Second, a booking-channel integration and a customer-data integration are different products with different approval paths. Note also that the same site describes SevenRooms as a DoorDash company and lists "Voice AI" among its own products, which means an integrator is asking a platform to open a booking surface next to a competing first-party feature.

Does Yelp's Reservations API let a third party create a booking?

Yes, and it is switched off by default. Yelp documents a four-step reservation flow publicly: Search for businesses supporting Yelp Reservations by date, time and party size; Openings for the available times at a business; Holds to place a temporary hold on a requested time; and Reservations, which creates the booking. The gate is stated on the same page: "Access is disabled by default. See Yelp Partner APIs on how to get access" and "Please note that access to this API is reserved for Yelp partners." (source: Yelp Reservations API, fetched 2026-09-05)

The create call is POST /v3/bookings/{business_id_or_alias}/reservations, and its published required parameters are name, date, time, first_name, last_name, phone, email, hold_id and unique_id. The covers, date and time must match what was supplied to the Holds endpoint - the hold is not optional plumbing, it is an input to the write. Calling the endpoint without an enabled client returns a documented refusal: "Partner API endpoints require set up by Yelp before they can be used. You are trying to access a Partner API endpoint for which your API Client has not been enabled."

Yelp is also the cleanest illustration of a distinction that trips up a lot of integration planning. The self-serve Fusion API, whose key you generate yourself when you create an app, exposes businesses, reviews, events, categories and autocomplete - and no reservations category at all. The reservation write lives in a separate, contracted product: "Access to these APIs are not enabled by default and are reserved for contracted Yelp partners", and "Each endpoint requires additional setup or a separate set of credentials." Yelp separately documents a Yelp AI API, but its own page describes it as enabling "developers to build conversational experiences for local business discovery" - discovery, not booking. Nothing on Yelp's own page as fetched on 5 September 2026 says the Yelp AI API creates reservations, so nothing here claims that it does.

Does TheFork publish a public create-reservation endpoint?

Yes. TheFork is the European platform in this set with a genuinely public API reference, readable without a login, and it documents the write directly: POST /v1/restaurants/:id/reservations, described as "Create a reservation at a restaurant, including the meal date, party size, and diner information." (source: TheFork Developers Portal, fetched 2026-09-05) A 401 on that endpoint is documented as "Error caused by an invalid or expired access token", which tells you the auth model without having to guess at it.

The B2B API is explicitly aimed at partners building their own booking funnel. Its introduction lists what a partner gets: "Design a booking flow matching your operational needs and brand requirements", "Access real-time availabilities", "Set up your own webhook", "Listen for events when reservations are created or updated", "Fetch reservation and customer details at your own pace." That is the full read-write loop an automated caller needs, described by the vendor.

Access is still contractual rather than self-serve, and TheFork is candid about it: "To obtain your credentials, you can contact our integrations team at integrations [at] thefork.com", and "include your company name and a brief description of your use case to speed up the approval process". Rate limiting is "enforced at the default level as outlined in your contract" - a contract is assumed. The B2B path uses an Auth0 client-credentials flow whose token "expires after 8600 seconds. When it does, repeat this process to get a new token", with a warning not to request a new one early because it "will overload the system with unused tokens"; the POS and Partners path uses an X-Api-Key header instead. One negative worth stating: no staging or sandbox environment is mentioned anywhere in those onboarding pages.

Is Reserve with Google an API you call to book a table?

No, and this is the most common misunderstanding in the whole space. Google Actions Center, the programme behind Reserve with Google, inverts the direction. You do not call Google to make a booking. You stand up a server and Google calls you. Google's own wording: "You need to stand up a booking server to allow the Actions Center to make callbacks to create and update bookings on your behalf." (source: Google, Implement the booking server, fetched 2026-09-05)

The methods the partner has to implement are listed by Google: HealthCheck (GET), BatchAvailabilityLookup (POST), CreateBooking (POST), UpdateBooking (POST), GetBookingStatus (POST) and ListBookings (POST). Google's reference for CreateBooking spells out who does the work: "The client requests to create a booking. The partner backend makes a booking for the requested slot, and returns the slot upon success, or business logic error." The partner backend is yours.

The security model is correspondingly old-fashioned and strict: "All requests Google will make to your booking server will be authenticated using HTTP basic authentication", "All communication to your booking server happens over HTTPS, so it's essential that your server has a valid TLS certificate that matches its DNS name", and "Passwords must be rotated every six months."

Which smaller platforms let you write a reservation programmatically?

Three, and they are the most permissive in the set - which is exactly the trade-off. The platforms that are easiest to integrate with are the ones with the smallest networks, and the ones with the biggest networks have the hardest gates. There is no platform in this audit that is both large and open.

Zenchef: writes supported, documentation issued to the restaurant

Zenchef publishes its supported-capability table openly even though the reference documentation is issued on request. Four rows on that table are marked as supported, worded by Zenchef as follows: "Check availability and opening hours of the restaurant"; "Create new reservations and modify existing reservations"; "Update the status of a reservation. For example cancel"; "Get notification when a reservation is made or updated". (source: Zenchef Help Center, article updated 2026-08-03, fetched 2026-09-05)

The gate has an unusual shape: it is the restaurant, not the developer, who asks. "The restaurant must have a Grow subscription or a special agreement must have been made", and "Let the restaurant send a request for the Zenchef API documentation and, if desired, a demo restaurant on our pre-production environment to help@zenchef.com." That pre-production demo restaurant is one of only three sandbox environments named by any platform in this audit; the other two are OpenTable's, granted on approval, and Google's Actions Center sandbox. Zenchef also reserves the right to pull the plug: "All calls are monitored by Zenchef. We trust our customers and partners to handle the Zenchef API responsibly. If not, Zenchef has the right to unilaterally shut down the integration." Its published rate guidance: "For calls that get an answer in less than 1s, it's possible to issue 100 per minute."

TableCheck: the fullest public specification in the set

TableCheck publishes a complete OpenAPI document at a public URL, no login required. The spec's own description: "The Booking API is used to book reservations directly into TableCheck's inventory backend." (source: TableCheck API Booking V1 OpenAPI spec, fetched 2026-09-05) The write is POST /reservations (operation id createReservation), alongside listing, updating, a cancel route, blockages, shops, menu items and reservation flags. Auth is an apiKey in the AUTHORIZATION header. One detail the spec makes unusually clear: the only server listed is https://api.tablecheck.com/api/booking/v1/, described as "Production (uses live data)". There is no sandbox server in the specification.

TableCheck's implementation guide adds the commercial gate and the flow. "The Booking API is available by special arrangement with TableCheck", and for anyone who is not a restaurant brand: "If you are a booking aggregator site (i.e. not a restaurant/hospitality brand), TableCheck must approve each venue individually for access", with access requested per shop by email. The documented write sequence is a blockage first, then the reservation: "Use POST /reservations to make a reservation. You must pass the Blockage ID to the reservation in this API call", and "This Blockage will expire after 5 minutes, however you can do PUT /blockage/{id} to renew the 5-minute expiry." Instead of a sandbox: "The Booking API allows the implementer to modify data. Please request the TableCheck API Team to prepare test data to facilitate your development." Published limitations are equally plain - "Payments are not supported", "Menu item (dining experience) booking is not supported", reservations cannot be cancelled if they are in the past or in "seated" status - and the rate limit is 10,000 requests per five-minute period, per API component, with HTTP 429 on exceed. (source: TableCheck, Booking v1 implementation guide, version 2026-05-14, fetched 2026-09-05)

resOS: the only one a developer can just start using

resOS publishes complete API documentation in public, including POST /v1/bookings ("Create booking"), a booking-flow group for dates, times and available tables, and endpoints for tables, opening hours, customers, custom fields and a health check. (source: resOS API v1.2 documentation, latest update stated as 2025-07-23, accessed 2026-09-05) Crucially, there is no partner application: "First ensure that the API app is enabled for your restaurant. If not, you can enable it from sidebar -> Apps. When it is enabled, head to your Settings page from the sidebar and find API credentials under the Apps category. On this page, you can view all your existing API keys and generate new ones. If none exist, simply click Generate key."

Auth is deliberately simple and correspondingly dangerous if mishandled: "The API key must be provided as the HTTP Basic Auth username in all requests. No password should be provided", with resOS' own warning attached - "Remember to keep this secret! Anyone with this key can perform all actions on resOS for your restaurant data. If used for our API, do not include this in front-end / client-side code, handle it all back-end / server-side." A CORS policy enforces that: "Requests to our API will fail from the frontend due to our CORS policy." The create call takes date, time, party size, duration, tables or an area id, and guest contact details, and it supports the waitlist: "Supports the waitlist feature, if enabled for the restaurant. To use, set the status field in the booking object to waitlist." One timezone trap is documented explicitly: "Please note if you are adding bookings with the DateTime field, it must be in UTC format. If adding as separate date and time fields, these must be in the restaurants' local timezone." The published rate limit is 100 requests per second.

Why does every restaurant booking API make you hold the slot first?

Across three independent vendors, the same pattern shows up: you cannot go straight to a write. You search availability, you lock the slot, and only then do you create the reservation - and the lock has a fixed, short lifetime set by the platform, not by you.

OpenTable documents its standard voice use case as exactly this sequence - "As a diner, I would like to make a reservation via the phone. The reservation does not have any applicable credit card restrictions or holds" - followed by Availability APIs (Search), Slot Lock, Make Reservation. And it states the constraint that matters most for a live conversation: "Slot Locks allow for the inventory that has been chosen by the booker to be locked for a total of 5 minutes", and "The five minute window is hard coded and cannot be edited."

For anyone designing an AI phone agent, five minutes is the real design constraint on this page. From the moment the agent offers a specific table and time, it has five minutes to collect a name, a mobile number capable of receiving an SMS and any special request, and to complete the write - or the lock lapses and the slot can be taken by someone else. That shapes the conversation: confirm the slot early, collect details in one pass, and do not park the caller on a long upsell mid-lock. The general mechanics of read-then-write booking integrations, lease conflicts and polled middleware are covered in our post on taking a message versus actually booking; what this page adds is that the restaurant platforms converge on the same five-minute number.

Which restaurant booking API can a developer get a key for without an approval?

One: resOS. Publicly documented does not mean publicly usable, and the gap between those two things is the single most useful thing to know before scoping an integration. Nine of the ten platforms in this audit require a human at the vendor to approve the integration before production credentials exist:

• OpenTable - "it is requisite to register and secure approval as an integration partner", plus a signed agreement, plus a QA process for voice AI partners.
• Yelp - "Access is disabled by default"; Partner APIs are "reserved for contracted Yelp partners".
• SevenRooms - "We only approve requests that come directly from our customers", and the documentation itself needs a provisioned account.
• Tock - Premium plans only, key issued by email to a named Account Owner (and the write you want does not exist anyway).
• TheFork - credentials issued by the integrations team after you describe your use case.
• Zenchef - a Grow subscription or a special agreement, with the restaurant requesting the docs.
• TableCheck - "available by special arrangement", and aggregators approved venue by venue.
• Google Actions Center - a direct contractual relationship with every merchant in your feed.
• Resy - no documentation to be approved for; the route is a sales conversation.
• resOS - no approval. The restaurant enables the API app and clicks Generate key.

This is worth contrasting with the appointment world, where a self-serve write API is normal: Square's Bookings API documents POST /v2/bookings publicly, gated on scopes and an Appointments subscription rather than on a partnership review. That comparison, and what integration depth really means, is worked through in our post on integration depth. Restaurants are the outlier: the reservation networks are the inventory, and they guard write access accordingly.

What does this mean for an AI phone agent that takes restaurant bookings?

It means the integration question has to be asked before the AI question, and it has to be asked platform by platform. A restaurant on OpenTable, TheFork, TableCheck, Zenchef, resOS or Yelp Reservations has a documented path to a written booking, subject in almost every case to an approval that takes vendor time rather than developer time. A restaurant on Tock does not have that path, because Tock says so. A restaurant on Resy or SevenRooms has a path that cannot be assessed from public documentation, which means the honest answer to "can you write into it?" is "we would have to ask them, and the request has to come from you".

Three practical consequences fall out of the audit:

• The approval gate is the schedule. On every large network, the long pole is the partner review, the contract and - for OpenTable's voice path - the quality-assurance pass, not the code. Plan the integration timeline around a vendor's review queue.
• The restaurant usually has to make the request. SevenRooms approves requests that come from its own customers. Zenchef expects the restaurant to ask for the documentation. Tock issues the key to a named Account Owner. An integrator cannot open these doors from the outside.
• Design for the caller the API refuses. OpenTable's voice path needs a mobile number that can receive an SMS and will not book ticketed experiences. Something has to happen for the diner calling from a landline and for the party asking about a ticketed event, and that something is a human, a callback or a message - decided in advance, not improvised on the call.

Where no write path exists, the agent still has real work to do. An AI voice agent answers every call 24/7, in over 100 languages, and transcribes each one, so the restaurant sees the request, the party size and the phone number even when the booking itself has to be entered by a human. That is a smaller claim than "it books into anything", and it is the one the documentation supports. For how this looks alongside a POS rather than a reservation platform, see our Toast and Square integration guide, and for the operational picture in a restaurant, AI phone answering for restaurants.

Every document cited on this page

• OpenTable API Documentation (Booking APIs, Getting Started, Environments, Platform Basics, Known limitations, FAQs) - docs.opentable.com. The site renders its content client-side; every quotation above is text a reader sees on that page, retrieved anonymously with no login and no key.
• Resy, Solutions for Hospitality Groups - resy.com/join/hospitality-groups; Resy software integrations - resy.com/join/integrations
• SevenRooms API Documentation notice - api-docs.sevenrooms.com; Restaurant API and Integrations - sevenrooms.com/platform/integrations-apis
• Tock, API FAQ (updated 2026-07-22) - tock.zendesk.com; Tock docs host - api.exploretock.com/docs
• Yelp Reservations API - docs.developer.yelp.com/docs/reservation; Reservations reference - v3_reservations; Yelp Partner APIs - yelp-partner-apis; Fusion Intro - fusion-intro
• TheFork Developers Portal: create reservation - B2B API specification; introduction - docs.thefork.io/B2B-API/introduction; preliminary steps - docs.thefork.io/preliminary-steps
• Google Actions Center: implement the booking server - booking server guide; CreateBooking method - reference; end-to-end overview - overview
• Zenchef API (Help Center article updated 2026-08-03) - help.zenchef.com
• TableCheck Booking V1 OpenAPI specification - api.tablecheck.com; implementation guide (version 2026-05-14) - Booking v1
• resOS API v1.2 documentation - resOS published API documentation
• Square, What the Bookings API does - developer.squareup.com

Frequently Asked Questions