Rescheduled Webhook starts_at Field Time Component

1

I am ingesting the rescheduled event webhooks. The field starts_at in the rescheduled events is a datetime, but the time component of the values are all 00:00:00.000000. An example of a complete value for the 'starts_atfield in the rescheduled events is2019-08-29 00:00:00.000000`.

Is there a reason why the field does not include the time component of the rescheduled meeting?

I haven’t yet checked the entire process flow on my side to see if there is a step that is changing these values. Writing into forum in the meantime to get resolution started.

2

I checked the raw webhook data in my companies Kibana. The field starts_at is coming through as 2019-08-29. The 00:00:000000 is being added when the field is saved as datetime data type is my guess.

This said, why is the start time not included on the starts_at field in the rescheduled event webhook?

3

Hi Phillip, I am sorry on the delay with a response. You can test out using {START-ISO} this will pull in the date format with a timestamp: 2019-12-02T10:15:00-0600. The {START-ISO} should update for reschedules as well.

4

I made the change to the payload. I’ll watch for a few to come through. It’s end of the day. Could take until tomorrow to verify that this change in the payload will solve the problem. I’ll mark answer as solution after I confirm that the field is coming through with the time.

5

I checked our logs for the change to the inbound rescheduled webhook. I’m still seeing YYYY-MM-DD. This example was received this morning. With some fields edited:
{"edited":{"name":"edited","version":"1","environment":"production","server":"edited","cmd":"cakephp","cakephp_log_item":{"message":""bookingId":"d873e66f-3103-4113-8079-7df2067ed5c3","bookingRef":"NVQR-OSCI-ZYXH","startsAt":"2019-12-04","endsAt":"18:30","timeZone":"Europe\/London","userId":"edited","rescheduledAt":"2019-12-04T16:19:21Z","rescheduledBy":"BOOKER"","type":"incoming_webhook","memoryUsage":3294728,"client_ip":"edited","method":"POST","path":"/webhooks/edited/rescheduled","status":200}}}

I also checked the payload for the event to make sure I followed the instructions and didn’t introduce a bug or typo. Current payload for the event:
{
“bookingId” : “{ID}”,
“bookingRef”: “{REF}”,
"startsAt": “{START-ISO}”,
“endsAt”: “{END-LOCAL-TIME}”,
“timeZone”: “{TIMEZONE}”,
“userId”: “{USER_ID}”,
“rescheduledAt”: “{RESCHEDULED-AT}”,
“rescheduledBy”: “{RESCHEDULED-BY}”
}

6

I changed it to:
"startsAt": "{START-ISO-8601}"

I’ll follow up on this thread with feedback on whether this solves the problem.

8

The format of startsAt in both my scheduled payload and the rescheduled payload are “startsAt”: “{START-ISO-8601}”. Yet, the format of the value for startsAt that is coming in on the rescheduled payload is still YYYY-MM-DD.

Is there a known bug with the format of the value provided for startsAt in the rescheduled payload?

9

Hi Phillip. I have setup debugging on your account to drill into the webhook issue a bit closer. The payload you have setup should be correct and I can see in the preview that the {START-ISO-8601} or {START-ISO} is in the format you are looking for. I will also test on my account and see what is happening here. Once I have more info I will reach out.

10

My test pulled through the correct formatting. The debugging didn’t yield anything further for your payload and what our system is passing through. The webhook in question is the native webhook feature not going through Zapier correct?