Preventing Overwrite of Existing Google Calendar Events with Schema.org Email Markup

56 Views Asked by At

I'm using Schema.org JSON-LD Email Markup to create event reservations in Google Calendar via Gmail. The markup is intended to generate unique events. However, when sending two distinct emails in succession with different reservation times, Google Calendar updates the existing event with the new details instead of creating a second, unique event.

For instance, the first email (Schema 1) uses a unique UUID for reservationId, setting an event from 08:00 to 08:30. The second email (Schema 2) also uses unique UUID but sets a different event from 09:00 to 09:30. Despite the differing UUIDs and times, Google Calendar is treating the second event as an update to the first.

Here's a simplified version of the email markups:

First Email Markup (Schema 1):

<!DOCTYPE html>
<html>
   <head>
      <script type="application/ld+json">
         {
           "@context": "http://schema.org",
           "@type": "EventReservation",
           "reservationNumber": "E12345", //I use UUID here
           "reservationStatus": "http://schema.org/Confirmed",
           "reservationId": "qwerty1234567",
           "underName": {
             "@type": "Person",
             "name": "Udhaya"
           },
           "reservationFor": {
             "@type": "Event",
             "name": "30 Min Meeting",
             "performer": {
               "@type": "Organization",
               "name": "Tech Park"
             },
             "startDate": "2023-11-10T08:00:00-08:00",
             "endDate": "2023-11-10T08:30:00-08:00",
             "location": {
               "@type": "Place",
               "name": "Tech Park",
               "address": {
                 "@type": "PostalAddress",
                 "streetAddress": "NA",
                 "addressLocality": "NA",
                 "addressRegion": "NA",
                 "postalCode": "NA",
                 "addressCountry": "United States"
               }
             }
           },
           "modifyReservationUrl": "https://example.com/reschedule/E12345",
           "ticketToken": "E12345",
           "ticketNumber": "E12345"
         }
      </script>
   </head>
   <body>
      ...Rest of my email
   </body>
</html>

Second Email Markup (Schema 2):

<!DOCTYPE html>
<html>
   <head>
      <script type="application/ld+json">
         {
           "@context": "http://schema.org",
           "@type": "EventReservation",
           "reservationNumber": "R98764",
           "reservationStatus": "http://schema.org/Confirmed",
           "reservationId": "asdfg3983", //I use UUID here
           "underName": {
             "@type": "Person",
             "name": "Udhaya"
           },
           "reservationFor": {
             "@type": "Event",
             "name": "30 Min Meeting",
             "performer": {
               "@type": "Organization",
               "name": "Tech Park"
             },
             "startDate": "2023-11-10T09:00:00-08:00",
             "endDate": "2023-11-10T09:30:00-08:00",
             "location": {
               "@type": "Place",
               "name": "Tech Park",
               "address": {
                 "@type": "PostalAddress",
                 "streetAddress": "NA",
                 "addressLocality": "NA",
                 "addressRegion": "NA",
                 "postalCode": "NA",
                 "addressCountry": "United States"
               }
             }
           },
           "modifyReservationUrl": "https://example.com/reschedule/R98764",
           "ticketToken": "R98764",
           "ticketNumber": "R98764"
         }
      </script>
   </head>
   <body>
      ...Rest of my email
   </body>
</html>

I've confirmed that each UUID is unique and the time slots do not overlap. The goal is for each email to create a separate event without affecting the other. Is there a known issue with Gmail's handling of back-to-back event emails that could cause this behavior? What steps can I take to ensure each email markup creates a unique event as intended?

Any advice or insights from the community would be greatly appreciated.

0

There are 0 best solutions below