Hello, we are using your API via Zapier to create Meeting Engagements on contacts whenever someone books a call through Calendly which is what we use for meeting schedules.
The times are correct on the contact and the engagement, but the "Duration" is incorrect. They are all showing as 15 Minutes instead of what should be 30 minutes (1:00-1:30)
Thanks for sharing. I've confirmed that the behavior is caused by epoch timestamps in seconds. A meeting's duration updates correctly with millisecond timestamps.
Zapier's documentation doesn't list millisecond timestamps as an option, so it can only send timestamps over in seconds. As such, there is no out-of-the-box solution to this issue.
I will work with my team to see if we can set meeting durations based on the differences between second timestamps. Alternatively, we may be able to transform the second timestamps to millisecond timestamps on our end. To be transparent, we will likely not be able to prioritize this change in the immediate future, so I apologize for any inconvenience.
I will update this thread with pertinent developments.
I'm happy to help, however I'm getting a 404 from that hubfs link.
To clarify, are these meeting engagements showing the correct times in the back end JSON, but not under "Duration" on the front end?
Could you share the support ticket number and perhaps a link to a contact record with an inaccurate engagement? I looked through your accounts but didn't see any open tickets citing this issue. I'd like to review my colleague's notes and continue digging for you.
Correct, the meeting times in the jQuery Hubspot provided me in a screenshot are correct 1:00 and 1:30 however the duration is showing incorrectly on the engagement. Its showing 15 Minutes when it should be 30 minutes.
Thanks for sharing that information. I'll close the loop with Steve.
I created a few MEETING engagements in my own account and the "Duration" correctly reflected the difference between the startTime and endTime I defined.
For example, this payload:
{
"engagement": {
"active": true,
"ownerId": 18624860,
"type": "MEETING",
"timestamp": 1561559798348
},
"associations": {
"contactIds": [100001],
"companyIds": [ ],
"dealIds": [ ],
"ownerIds": [ ]
},
"metadata": {
"body": "I had a 3:30 hour meeting with Sam.",
"startTime": 1561554000000,
"endTime": 1561566600000,
"title": "My 3.5 Hour Meeting"
}
}
renders as:
While the meeting with this contact has UNIX timestamps for startTime and endTime that come out to 30 minutes apart (1562072400 and 1562074200, respectively), they are in seconds rather than milliseconds. HubSpot's APIs accept millisecond timestamps, so I'm a bit surprised the engagement was accepted and placed on the timeline in 2019 instead of 1970.
That abnormality aside, I suspect that HubSpot had trouble calculating the difference between these second timestamps and automatically set the "Duration" to "15 minutes" because that is the shortest default duration for meetings.
Are you seeing this behavior across all meeting engagements? Could you provide additional examples?
If all MEETING engagements are coming through with second timestamps, we'll likely have to work with Zapier to get millisecond timestamps sent over.
Thanks for sharing. I've confirmed that the behavior is caused by epoch timestamps in seconds. A meeting's duration updates correctly with millisecond timestamps.
Zapier's documentation doesn't list millisecond timestamps as an option, so it can only send timestamps over in seconds. As such, there is no out-of-the-box solution to this issue.
I will work with my team to see if we can set meeting durations based on the differences between second timestamps. Alternatively, we may be able to transform the second timestamps to millisecond timestamps on our end. To be transparent, we will likely not be able to prioritize this change in the immediate future, so I apologize for any inconvenience.
I will update this thread with pertinent developments.