TableCheck is an online reservation booking platform used in over 3,000 restaurants in over 20 countries around the globe, with over 100 million diners seated. Restaurants use TableCheck and its associated applications and services to efficiently manage their reservations, table availability, and guest data. TableCheck provides a set of API endpoints to allow integration between third-party booking engines, Customer Relationship Management (CRM) systems, Point-of-Sale (POS) systems, and more.

The API

The API is a JSON document-based API which follows the REST (Representational State Transfer) pattern. Each URL endpoint provided by the API uses the HTTP GET, POST, PUT, and DELETE requests to read, create, update, and delete documents.

Environments

TableCheck provides only a Production API environment. If requested, TableCheck’s API Team (api@tablecheck.com) can prepare separate “Test” and “Live” API accounts to facilitate your system development. We will also help prepare test data as needed.

Environment	Root URL

Environment	Root URL
Production	`https://api.tablecheck.com/api/`

Authentication

A secret_key is used to authenticate your API access. Set it in the "Authorization" HTTP header on each API request.

Always keep your secret_key a secret. Do not commit it source control.

One secret_key for each environment will provided to you by API Team (api@tablecheck.com) at the time your API access is approved. If you believe your secret key has been compromised, please request the API Team to roll a new key and update it on your server.

Requests

Protocol

All requests must use HTTPS (port 443). Requests via HTTP (port 80) will receive a 3xx response redirecting to the corresponding HTTPS endpoint.

URL

Unless otherwise noted, the API generally uses the following URL path segmentation scheme:

/<component>/<component_version>/<resource_type>(/<resource_id>)

Segment	Meaning

Segment	Meaning
`component`	The code of the specific API Component being accessed. Example: `pos`
`component_version`	The major version of the component. Example: `v1`
`resource_type`	The name of the resource being accessed, often but not always pluralized. Example: `customers`
`resource_id`	For GET, PUT, and DELETE requests, the ID of the resource being accessed. Typically in 24-char hex format. Example: d`2dbe2384bf56b90a8a70f0a`

HTTP Headers

The API requires the following HTTP Headers on every request:

HTTP Header	Value

HTTP Header	Value
`Authorization`	`<secret_key>`
`Accept`	`application/json`
`Content-Type`	`application/json`

Responses

HTTP Status Codes

The API returns HTTP status codes as follows:

Code	Type	Meaning

Code	Type	Meaning
`2xx`	Success	A 2xx status indicates a successful response.
`3xx`	Redirection	A 3xx status response occurs when TableCheck has moved an API endpoint.
`4xx`	Client Error	A 4xx status response occurs when your request is invalid, malformed, or lacks proper authentication.
`5xx`	Server Error	A 5xx status occurs when TableCheck's infrastructure has failed and/or is temporarily unable to process your request.

How to Handle 3xx Redirects

Please ensure your HTTP client can follow redirects as per 3xx status code meaning.

How to Handle 4xx Errors

4xx status indicates that a repeated attempt of the same request is expected to fail. When you receive a 4xx status response, give up and and do not retry your request. Instead, inspect the particular HTTP status code and response body for error message in either JSON or text/plain format. Example:

Status: 422 (Unprocessable Entity)

{
  "errors": [
    { message: "Name cannot be blank" },
    { message: "Phone format is invalid" }
  ]
}

How to Handle 5xx Failures

5xx status indicates that a repeated attempt of the same request is expected to succeed. When you receive a 5xx status response, depending on context you may wait several seconds then try the same again. For requests that are not time-sensitive, for example, syncing of customer data, we recommend to implement an exponential back-off time function and retry up to 20 times over a 24 hour period, then give up.

As 5xx failures occur at the infrastructure level, note that the response body may be empty on in a content format other than JSON.

Please design your system with the anticipation that sporadic 5xx failures may occur from time to time. Isolated occurrences of 5xx failures do not need to be reported to our Support team, and our Support team will not provide support for them.

Document Format

All documents submitted to and returned from the API are in JSON format. XML and other formats are not supported.

Attribute Casing

Attribute names within JSON documents are snake_case. For example, the following POST to /crm/v1/customers won't work because first_name is capitalized:

{
  "customer": {
    "FirstName": "Ricky",
    "last_name": "Ricardo",
    "memo": "He loves Lucy"
  }
}

Pagination and Metadata

The root nodes pagination and meta will be reserved for pagination data and other metadata respectively.

Character Escaping

Certain HTML and Unicode characters will be escaped in JSON responses. For example, the character > will be escaped as \u003E. Characters may optionally be escaped in requests.

Data Types

The API returns and accepts JSON values, which can be strings in double quotes, numbers, objects, arrays, true or false, or null. All programming languages have tools to parse JSON data.

The following application-specific data type conventions are used:

Format	JSON Type	Description	Example

Format	JSON Type	Description	Example
`integer`	`number`	An integer number, i.e. without a decimal place.	`6174`
`float`	`number`	A floating point number, i.e. with a decimal place.	`2.718`
`decimal`	`string`	A string representing a decimal number. Used to prevent loss-of-precision when working with monetary data.	`"1207.5"`
`bson-id`	`string`	A 24-char hexadecimal (0-9, a-f) string. In cases where an object's ID is of another type (such as an integer) it will be indicated accordingly.	`"2ddbe2384bf56b90a8a70f0a"`
`date-time`	`string`	UTC time and are formatted as ISO 8601 strings.	`"2022-04-16T09:14:57Z"`
`date`	`string`	Date values are timezone-independent and formatted as ISO 8601 date strings.	`"2022-04-16"`
`seconds`	`number`	A quantity of seconds, represented an integer.	`900`
`currency`	`string`	An ISO 4217 three character currency code.	`"EUR"`
`country`	`string`	An ISO 3166-1 alpha-2 two character country code	`"US"`
`time-zone`	`string`	An IANA tz database time zone identifier.	`"Asia/Tokyo"`
`phone-e164`	`string`	A phone number in E.164 format, including the leading plus-sign (+) character.	`"+818011112222"`
`url`	`string`	A URL containing the HTTP schema at the beginning.	`"https://www.tablecheck.com/my/path"`
`http-status`	`number`	An integer representing an HTTP response status code.	`200`
`locale`	`string`	An ISO 639-1 locale code. Refer to Internationalization (I18n) below.	`"en"`
`translations`	`object<string, string>`	An object representing a set of language translations. Refer to Internationalization (I18n) below.	`{ "en": "Hello", "fr": "Bonjour", "ja": "こんにちは" }`
`comma-separated`	`string`	A list of values delimited with a comma (,) character.	`"dog,cat,rabbit"`

Internationalization (I18n)

TableCheck supports the following ISO 639-1 locale codes uniformly across all products and APIs:

`ar`	Arabic	`it`	Italian	`ru`	Russian
`en`	English	`ja`	Japanese	`tl`	Tagalog
`de`	German	`ko`	Korean	`th`	Thai
`es`	Spanish	`lo`	Lao	`vi`	Vietnamese
`fr`	French	`my`	Malay	`zh-CN`	Chinese (Simplified)
`id`	Indonesian	`pt`	Portguese	`zh-TW`	Chinese (Traditional)

New locale codes may be added without warning. When building your integration, please consider how to handle newly introduced codes.

Given an Translations object:

First, look for an exact match of the user's specified locale or browser locale.
If not available, attempt to fallback to another locale with the same language base code. For example, zh-CN should fallback to zh-TW
If not available, fallback to en (English)
If English is not available, choose from one of the available locale codes.

Getting Started