NAV
shell

Platform Policy

Permitted Use of APIs

You may use the OpenTable application program interface (“API”) and any data provided through an API only in accordance with your applicable agreement with OpenTable (“Terms”), this Platform Policy and OpenTable’s applicable API documentation and policies. In this Platform Policy, “you” means the entity which agreed to the Terms with OpenTable. In event of any conflict between this Platform Policy and the Terms, this Platform Policy will control as relates to the API. Otherwise, the Terms continue to apply to the API and any activity under this Platform Policy.

You will only access (or attempt to access) an API by the means described in the documentation for that API. If OpenTable assigns you credentials (e.g. client IDs), you must use them only with the applicable APIs. You may not share your credentials with third-parties or service providers without OpenTable’s consent (and if such parties require access you must request individual credentials for them). Your API usage rights are limited, non-exclusive, non-sublicensable and non-transferable.

OpenTable may set and enforce limits on your use of the APIs (e.g. limiting the number of API requests that you may make or the number of users you may serve), in its sole discretion. You agree to, and will not attempt to circumvent, such limitations documented with each API. If you would like to use any API beyond these limits, you must obtain OpenTable’s express written consent (and OpenTable may decline such request or condition acceptance on your agreement to additional terms and/or charges for that use).

You agree not to (and not to authorize any third party) to: 1. Use the APIs other than as permitted; 2. Modify or create any derivative works of the APIs; 3. Distribute, sell or sublicense the APIs or use them on behalf of third parties (unless expressly permitted in the Terms); 4. Introduce any viruses, worms, Trojan horses, or other harmful code to OpenTable via the APIs; 5. Attempt to interfere with the proper working of the APIs or OpenTable products, services or systems or compromise their integrity or security; 6. Scrape any OpenTable website or system for data, or otherwise seek to access data or OpenTable materials through means not approved by OpenTable in writing; or 7. Use the APIs in a manner or for a purpose that violates laws or third-party rights; 8. Access the APIs for competitive analysis or disseminate performance information (including uptime, response time and/or benchmarks) relating to the APIs or OpenTable products, services or systems.

Data and Security

You may use any data made available through the APIs solely as permitted in the Terms or otherwise expressly permitted in writing by OpenTable. OpenTable does not grant you any other rights to data.

Without limiting any security requirements in the Terms, you agree to provide the level of protection to any such data as required under applicable law and to employ, at your own cost, appropriate physical, technical and organizational security measures designed to protect such data from unauthorized access, destruction, use, modification or disclosure.

Changes, Suspension and Termination

From time to time in its discretion, with or without notice, OpenTable may change the APIs (including any API documentation) or related Open Table products or services, discontinue any or all data available through the APIs or to specific recipients, or place limits on access to the APIs. Future versions of the APIs may not be compatible with systems used with previous versions. OpenTable typically makes these changes as part of its overall API program and is unable to provide individual notices of the changes.

Except as set forth in the Terms, OpenTable may suspend or terminate your access to the APIs (in whole or in part) in its discretion, for any or no reason and with or without notice.

OpenTable will have no liability resulting from taking any actions described in this Section.

No Support or Maintenance

You understand that you are responsible for all development and costs associated with integrating with the APIs.

OpenTable has no obligation to provide any maintenance or support for the APIs or to fix any errors or defects. If OpenTable in its discretion provides any updates, modifications, enhancements, and other new releases to the APIs, such materials will be deemed included in the “APIs” under this Platform Policy unless OpenTable specifies otherwise.

OpenTable Rights

OpenTable owns all right, title and interest (including intellectual property rights) in and to the API. OpenTable reserves all rights not expressly granted.

Disclaimer

EXCEPT AS EXPRESSLY SET OUT IN THE TERMS, OPENTABLE MAKES NO SPECIFIC PROMISES ABOUT THE APIS. FOR EXAMPLE, OPENTABLE DOES NOT MAKE ANY COMMITMENTS ABOUT THE DATA OR CONTENT ACCESSED THROUGH THE APIS, THE SPECIFIC FUNCTIONS OF THE APIS, OR THEIR RELIABILITY, AVAILABILITY, SECURITY OR ABILITY TO MEET YOUR NEEDS. OPENTABLE PROVIDES THE APIS “AS IS” AND “WITH ALL FAULTS”. EXCEPT AS EXPRESSLY PROVIDED FOR IN THE TERMS, TO THE EXTENT PERMITTED BY LAW, OPENTABLE AND ITS THIRD PARTY LICENSORS DISCLAIMS ALL WARRANTIES, GUARANTEES, CONDITIONS, REPRESENTATIONS, AND UNDERTAKINGS, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT AND FITNESS FOR ANY PURPOSE.

Last Updated: June 12, 2019

Terms of Use and Privacy Policy

Terms of Use

Privacy Policy

Platform Basics

OpenTable uses OAuth 2.0 as the primary authorization mechanism. This means that an access token must be obtained and submitted with all requests. See Authorization section for more details.OpenTable’s Network Partner APIs can only be accessed via HTTPS. This applies to all environments.

Content Negotiation

Data is sent and received in JSON format unless otherwise specified in this documentation. Clients should specify application/json in the Accept header for all requests to the server.

Compression

OpenTable’s Partner Network APIs support LZ4 encoding. Client application should specify lz4 via the Accept-Encoding HTTP header whenever possible.

Unique Request Ids

All POST, PUT, and PATCH HTTP requests should contain a unique X-Request-Id header which is used to ensure idempotent message processing in case of a retry

Host Names

OpenTable has two primary integration environments; pre-production and production. Partners should test their integrations in pre-production where the changes are transient and do not affect live production customers or restaurants. Once partners have completed their integrations they may deploy them into the production environment. The following table lists the key hosts in each environment.

Environment Host Name
Production platform.opentable.com
Pre-production platform.otqa.com

Authorization

OpenTable uses OAuth 2.0 to authorize access to protected resources. Authorization involves following steps:

Obtaining an Access Token

Environment OAuth Base URL
Pre-production https://oauth-pp.opentable.com/
Production https://oauth.opentable.com/
curl --user username:password -X POST \
'https://oauth-pp.opentable.com/api/v2/oauth/token?grant_type=client_credentials'

OpenTable response :: HTTP 1.1 200 OK



{
"access_token": "a1c7b724-0a20-42be-9dd4-23d873db1f9b",
"token_type": "bearer",
"expires_in": 2419181,
"scope": "DEFAULT"
}

Clients can obtain an access token using the OAuth 2.0 client credentials flow.

URI

https://oauth.opentable.com/api/v2/oauth/token?grant_type=client_credentials

Request Parameters

Member Description
grant_type OAuth grant type. Should be “client_credentials”

Submitting Client Credentials

Client credentials are submitted in the Authorization header as defined in the OAuth spec. Given a client id (e.g., “client_id”) and a client secret (e.g., “client_secret”), you need to do the following:

  1. Concatenate them using a “:” (e.g., “client_id:client_secret”)
  2. Base64 encode the result from step 1 (e.g., “Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=”)
  3. Set the header “Authorization: Basic <result from step 2>” (e.g., “Authorization: Basic Y2xpZW50X2lkOmNsaWVudF9zZWNyZXQ=”)

Authorizing Requests

Authorization: bearer a1c7b724-0a20-42be-9dd4-23d873db1f9b”)

  1. Obtain an access token
  2. Set the header “Authorization: bearer <result from step 1>” (e.g., “Authorization: bearer a1c7b724-0a20-42be-9dd4-23d873db1f9b”)
  3. Send the request a. If the token is valid and not expired, an appropriate response from the resource server will be returned. b. If the token is not valid, the resource server responds using the appropriate HTTP status code (typically, 400, 401, 403, or 405) and an error code https://tools.ietf.org/html/rfc6750#section-3.1

Token Renewal

Token expiry is included in the response. To get a new token, simply follow the process Submitting Client Credentials to obtain a new one.

Responses

OpenTable Response :: HTTP 1.1 400 Bad Request

json { "error": "invalid_request", "message": "oauth token is required to access this resource" }

OpenTable Response :: HTTP 1.1 401 Unauthorized

json { "error": "invalid_token", "message": "b7721d39-65f6-4b6a-8686-3af5246e5b3a" }

Affiliates Guide

Introduction

This section contains instructions to retrieve the directory information of all OpenTable restaurants and Implement reservation links to OpenTable.com, the OpenTable iOS app, and OpenTable Android app. This provides affiliates with the ability to easily link to restaurants that accept online reservations via OpenTable.

Requesting a Client Id

Self-registration for the Directory API is now available.

Retrieving Restaurant Data via Directory API

The Directory API returns a complete directory of restaurants that accept online reservations via OpenTable so that will need to first be called. The restaurant directory will be returned by the API in JSON format. The links can then be built using the data returned by the Directory API. The restaurant data is refreshed nightly, so it is recommended to call the API at least once a day to get the most current restaurant directory data.

API Access

To retrieve the data using the Directory API and linking to the reservation pages on OpenTable, the following are required:

  1. OAuth Key and Secret: Provided by OpenTable. Instructions for obtaining an access token using the key/secret pair is described in the Authorization section.
  2. ReferralID: Provided by OpenTable.

API Usage

Refer to the Directory API technical documentation for implementation details.

Linking Guidelines

Affiliates must comply with the following guidelines when using OpenTable data and linking to the OpenTable site

Linking to Individual Restaurants on OpenTable.com

The process of linking to each restaurant’s reservation page involves using the natural_profile_url value contained in the JSON response of the Directory API for each restaurant, along with your unique referral ID which is provided by OpenTable:

https://www.opentable.com/boulevard-san-francisco?ref=zzzz

where “https://www.opentable.com/r/boulevard-san-francisco” is the restaurant’s natural_profile_url value as returned from the Directory API and zzzz is the numerical referral ID (this allows OpenTable to track reservations coming from your site). As an example, the link for Boulevard San Francisco for a referral ID of 1234: https://www.opentable.com/r/boulevard-san-francisco?ref=1234

Country URL
North America https://www.opentable.com/boulevard-san-francisco?ref=zzzz
UK https://www.opentable.co.uk/boulevard-san-francisco?ref=zzzz
Australia https://www.opentable.com.au/boulevard-san-francisco?ref=zzzz
Germany https://www.opentable.de/boulevard-san-francisco?ref=zzzz
Japan https://www.opentable.jp/boulevard-san-francisco?ref=zzzz
France https://www.opentable.fr/boulevard-san-francisco?ref=zzzz
Spain https://www.opentable.es/boulevard-san-francisco?ref=zzzz
Mexico https://www.opentable.com.mx/boulevard-san-francisco?ref=zzzz
Canada https://www.opentable.ca/boulevard-san-francisco?ref=zzzz
Hong Kong https://www.opentable.hk/boulevard-san-francisco?ref=zzzz
Ireland https://www.opentable.ie/boulevard-san-francisco?ref=zzzz
Singapore https://www.opentable.sg/boulevard-san-francisco?ref=zzzz
Netherlands https://www.opentable.nl/boulevard-san-francisco?ref=zzzz
United Arab Emirates https://www.opentable.ae/boulevard-san-francisco?ref=zzzz
Thailand https://www.opentable.co.th/boulevard-san-francisco?ref=zzzz
Italy https://www.opentable.it/boulevard-san-francisco?ref=zzzz

“Deep Linking” into the OpenTable iOS App

The OpenTable iOS app supports universal links (e.g., opening desktop/mobile web links directly into the app).

This is the preferred way of deep linking into the app. The main benefit is that these links will always work, even if the app is not installed, taking the user to Safari.

Brand Assets

Affiliates must comply with the OpenTable bran guidelines when linking to the OpenTable site:

Assets Location
OpenTable Logo http://brand.opentable.com/logo#downloads
Reserve Buttons http://brand.opentable.com/partner-assets
Brand Story http://brand.opentable.com/brand-story

The following table outlines the applicable query parameters for this endpoint.

        PARAMETER ACCESS  DESCRIPTION 
offset
integer
public The offset to fetch results at.
limit
integer
public The maximum number of results to return. If this parameter is not specified the API will return up to 100 directory results per call.
country
string
public The API will only return restaurants that exist in the specified country.

Error Response DTO

Error response DTO returned by APIs is in the below format.

{
    "errors": [
        {
            "message": "user-readable error description"
        }
    ],
    "requestid": "2f6c6799-e560-40bb-880f-3ca8e8cdb71c"
}
        PARAMETER DESCRIPTION 
errors
array
An array of entities with error description.
message
string
Short description of the error.
requestid
string
Unique request identifier which can be used by OpenTable to investigate this error.

Backward compatibility

What changes does Opentable consider to be “backwards-compatible”?