API partners & GDPR compliance

As you are probably aware, tech companies active within the EU have been working to ensure that their solutions are GDPR Compliant by the legal deadline of May 25th 2018.

At ResDiary we’re no different. The legal obligations have meant that we’ve had to make a number of changes to the core ResDiary application. Part of these changes are to:

a. our customer profile structure and how we record marketing opt-ins.

b. storing the marketing opt in message provided to the diner when opting-in.

These changes have a ripple-on effect of meaning that all our API partners that have built bespoke booking systems will need to make adjustments to their integrations.

The GDPR changes

Email & SMS marketing opt-in

Our system data structure previously assumed that when a customer opted-in to marketing, they did this at the Restaurant Group Level, meaning that we recorded that they were opting into marketing from any restaurant within the organisation. Note: if the venue is a single-site-business, this opt-in is entirely correct.

As part of our GDPR-related changes, we added the ability to record a customer’s opt-in at both restaurant group level, and/or the restaurant level.

Note: the previous opt-in is mapped at the restaurant group level. Therefore, if your integration relates to a restaurant that exists in a restaurant group, you must take action to ensure this is accurately reflected in your online booking process.

Note: if your integration relates to a single site, we recommend that you address the issue completely, regardless, to ensure that your online booking process is future-proof and the restaurant’s marketing database is maintained in the manner ResDiary users would expect.

Marketing opt-in text

In order for restaurants to meet the legal requirements of GDPR-compliance, and continue to market to their database, it’s now a legal requirement for the ResDiary system to store the marketing opt-in message.

Therefore, you must take action to code to the new API end point, and send this information to the ResDiary system.

The API changes

We have altered both our create_booking API calls with the new attributes. See:

> Old: POST-api-ConsumerApi-v1-Restaurant-micrositeName-Booking

> New: POST-api-ConsumerApi-v1-Restaurant-micrositeName-BookingWithStripeToken

The additional attributes are found in the create_booking nested within the customer object

“Customer”: {

   “Email”: “sample string 7”,
   “ReceiveEmailMarketing”: mapped to group level,
   “ReceiveSmsMarketing”: mapped to group level,
   “GroupEmailMarketingOptInText”: mandatory property”,
   “GroupSmsMarketingOptInText”:mandatory property”,
   “ReceiveRestaurantEmailMarketing”: “mandatory property if individual venue opt-in enabled, optional otherwise”
   “ReceiveRestaurantSmsMarketing”: “mandatory property if individual venue opt-in enabled, optional otherwise”
   “RestaurantEmailMarketingOptInText”: “mandatory property if individual venue opt-in enabled, optional otherwise”
   “RestaurantSmsMarketingOptInText”: “mandatory property if individual venue opt-in enabled, optional otherwise”

},

Changes being added in Release 11.8

From the restaurant setup api call you can retrieve the restaurants preference of which ‘opt in’ and which ‘marketing text’ should be used. See:
GET-api-ConsumerApi-v1-Restaurant-micrositeName-Setup_date_channelCode

“RestaurantGroupName”: “the name of the group in ResDiary use the Group Marketing Name to display as the preference,
 “IsGroupRestaurant”: true,
 “IsIndividualVenueMarketingEnabled”: true,
 “IsGroupMarketingEnabled”: true,
 “GroupMarketingDisplayName”: “the consumer facing name of the group”,

If a restaurant is both ‘Site’ and ‘Group’ marketing enabled then this indicates that the restaurant would like to present both ‘Site’ and ‘Group’ marketing opt ins.

Need to talk to us?