Yes, to do that you’ll implement that in your perform method. It’s not a function that’s handled automatically.

Whatever secret material (secret or signature verification key, etc) you’ll use to verify the token for messages on that subscription will need to be provided by your API in the subscription response. In your perform method you’d then access it from bundle.subscribeData when you’re validating the message. This is the most common flow I’ve discussed with folks, but there’s probably other options for sharing secrets and validating the message.

Let us know if you want to dig into a design or solution approach more.

Thanks for the response. Just to clarify my original question, I was referring to security best practice to Confirming Receiver's Intent to Subscribe. I believe the receiver in this context will be Zapier trigger.

As described, a confirmation HTTP call is made to the hook URL which should simply return the token generated by the Sender (in case, of immediate confirmation). At this point, “bundle.subscribeData” is not available as it is not being created and is only available after the subscription is created.

Ah! Thanks for the clarification. So sending an subscription ack with a challenge to your server, rather than your integration validating the message. 

We actually do not support that today, and there’s no way to customize that behavior yourself. Hook message processing is asynchronous - a gateway receives the message, sends a HTTP 20x response, and closes the connection before your integration ever gets a handle to that message. 

This is actually something I’ve wanted to support for ages, but not something that’s immediately forthcoming - there’s a few challenges to getting it done in a way that works for all the various header names and variations we’ve seen of server implementations.

Thanks for confirming this. I will make changes to accommodate our Zapier use case.