CRM v1

The CRM API is used by restaurant operators to obtain full customer, reservation, membership, and other related data from the TableCheck system.

Target Audience

The CRM API gives access to sensitive customer information, and therefore should only be used by:

• Restaurant franchises who wish to access their customer data, e.g. for marketing purposes

• Restaurant-designated third-party systems such as CRM (Customer Relationship Manager), CDP (Customer Data Platform), PMS (Property Management System), and loyalty programs

The CRM API is not intended for use by third-party booking sites, concierges, travel portals, etc. who should not have access to sensitive customer information.

Endpoint

The CRM allows the implementer to modify data.

Interactive API console

https://api.tablecheck.com/api/crm/v1/docs

Refer to Using the API Console for help.

Rate Limits

Data Types

The CRM API provides access to the following data types:

Shops	Lists the Shops (restaurant outlets) which can be accessed.
Reservations	Lists Reservations across all Shops, including the Customer data for the reservation.
Customers	Lists Customers across all Shops. Also includes Membership data.
	Create and modify Customers.
Memberships	Lists Customers' loyalty program Memberships
MembershipPrograms	Lists loyalty programs and membership tiers (gold, platinum, etc.) for each program.

Integration Examples

Create a new Customer

🔗 API Console

Modify an existing Customer

🔗 API Console

Delete a Customer

🔗 API Console

Search for Customers

🔗 API Console

Use the POST /customer_search endpoint to find customers. Refer to the API docs for a full list of supported search parameters.

Bulk Exporting Customer Data

🔗 API Console

Use the POST /customer_search endpoint for bulk data exports, including downloading your entire customer database.

The endpoint will return 200 results at once. To fetch the next page of results, use the pagination.scroll_id value from the response in the POST request body as follows:

The response to this request will include a new pagination.scroll_id value. Use this new value in your next query in a loop until there are no more results returned. The scroll_id value will expire if not used within 5 minutes. When using the scroll_id parameter, it is not necessary to retransmit your search parameter parameters from the original request.

Receiving Notifications when Data Changes

Please refer to the Sync API for instructions on how to receive notifications when data objects (including Customers, etc.) are changed on the TableCheck side.

Modifying Customer Phone Numbers and Email Addresses

The Customer object contains several nested objects, includes phones, emails, addresses, events (birthday, anniversary, etc.), and socials (SNS accounts).

The Customer response object (e.g. GET /crm/v1/customers/{id}) returns phones and emails as an array of strings, and additionally has phone_objects and email_objects which represent the full objects. Note the two formats represent the same underlying content. Phones must be in E.164 format.

To modify nested objects via PUT /crm/v1/customers/{id}, you may reference them by their object IDs. Use the _destroy: true attribute to delete a nested object.

Alternatively, you may transmit phones and emails as an array of string. By default, any phones / emails you set in this manner will be appended to the existing phones / emailsof the Customer. To overwrite existing, use the overwrite_phones: true and overwrite_emails: true parameters.

The overwrite_phones, overwrite_emails, overwrite_addresses, etc. parameters can also be combined with the object-based format above.

Merging Customer Records

It is possible to merge Customer objects using the merge_customer_ids parameter:

Here the Customer identified by {id} in the URL path is the primary ("victor") and remains post-merge. The Customers listed in merge_customer_ids are secondary ("victims") and are destroyed after merging. All associated objects (e.g., Reservations, Memberships, Images) from the secondary Customers transfer to the primary Customer. This transfer happens asynchronously; it may take several minutes for all associated objects to correctly reflect the new customer ID.

Merging does not automatically combine individual data fields like first_name, last_name, emails, and phones. You must manually resolve conflicts and set these fields on the subject Customer, which may be done in the same API call. For example, to merge a Customer and update the subject Customer’s first_name and phones, structure your API call as follows:

Lastly, in the Customer response, you may refer to the merged_customer_ids field to reconcile which other Customers have been historically merged into the subject Customer. Since the other Customers will have already been destroyed, it will not actually be possible to query them using the IDs.

Uploading Customer Images on Customer Creation

🔗 API Console

You can upload images during customer creation. We accept image urls in the request via the image_upload_url key.

You are allowed to upload multiple images at once.

There is no limit to the number of images you may upload.

The maximum file size is 20 GB.

The following image MIME types are allowed

• image/jpg

• image/jpeg

• image/png

• image/gif

• image/bmp

• image/heic

• image/tiff

• image/webp

• image/svg+xml

Upon successful upload the images will contain the url and image_variants

Uploading and Deleting Customer Images on Customer Update

🔗 API Console

You can upload or delete images while updating a customer.

To delete an image apply the id of the image and _destroy key with a Boolean value of true.

You may also upload or destroy multiple images at the same time.