Hey everyone, we are using the infrastructure version and wondering if there is already a way to pass additional metadata at the time of booking that would be included in the webhook payloads. More context: During the booking process we want to capture information that we pass onto the URL such us unique identifiers that tie that booking to our backend systems. In our case we don’t want to make these fields visible nor editable by the user in the same way that “additional inputs” are. Many thanks, Alex

@Bailey dont we have a youtube video for that? where did it go

thanks @Peer do lmk if u find that video.

One more thing @Peer, @Bailey does your webhook issue a security signature that we can verify as part of the payload? Do you have docs/samples on that regard? We are trying to ensure the request is a trusted request.

that is great to hear. we intend to record more of those videos

We can add this ourselves but it would be something good to have on your saas offering. I did notice you have the ability to customize the payload so this may allow for a workaround - at least adding a static api-key. @Peer

agree. feel free to make a PR 🙏

One more thing @Peer, @Bailey does your webhook issue a security signature that we can verify as part of the payload? Do you have docs/samples on that regard? We are trying to ensure the request is a trusted request.

Currently we don't but I think it's a good idea to do that. I'll add this to TODO for the coming weeks/months.

@Ali take a look at the Twilio implementation of their X-Twilio-Signature - it's a good point of reference. I can help if needed. https://www.twilio.com/blog/how-to-secure-twilio-webhook-urls-in-nodejs https://www.twilio.com/docs/usage/webhooks/webhooks-security

function getSignature(authToken, url, params) {
  // get all request parameters
  var data = Object.keys(params)
     // sort them
    .sort()
     // concatenate them to a string
    .reduce((acc, key) => acc + key + params[key], url);

  return crypto
     // sign the string with sha1 using your AuthToken
    .createHmac('sha1', authToken)
    .update(Buffer.from(data, 'utf-8'))
     // base64 encode it
    .digest('base64');
}

Hi @Alex Dowbor I'll have to check this. I'll get back to you on this.

Hi @Ali, it's mainly a matter of consistency so that we can tie the events to unique identifiers our backend. We have a Salesforce integration and we always provide the event link including metadata with the customer_id and other bits that help us take actions when they book, cancel or reschedule. For that reason, it's important that the same metadata provided at creation is also available at cancel and reschedule. Otherwise, we need to use the cal booking id which we would need to store from the booking to try to reconcile - btw, I think on reschedule you send a new booking id anyway (but don't quote me on that... i just heard from someone on the team and may have misunderstood it). Hope this helps.

Yeah, we do send new booking id in reschedule.

@Ali in that case do you provide the previous-booking-id as well to help with the reconciliation? That may be an idea.