That was really helpful and it works like a charm.
Last question: Above method was needed to verify the Webhook URL with Facebook. Once thats done however, Facebook will use this very same Webhook URL going forward to send new lead data to via a POST request. The thing is, it will always be sent to the very SAME URL we verified before (meaning that the same URL must be able to both listen to GET and POST). Unfortunately I had no luck creating another Webhook with the POST method to listen to while having the very same URL. How would you go about this?
The easiest would probably be to simply have an IF directly after the node. If “hub.mode” is subscribe it goes to the Set-Node and returns what it wants. If not it does whatever else you want.
So, I did as you said and implemented an IF after the node, and the verification works. However if the Request from FB is a POST (to send lead data) instead of GET (to verify), it doesn’t even trigger the webhook as it is only listening to GET. How can I get the webhook to listen to both GET and POST?
Ah one request come via “POST” and the other one via “GET”. In that case there is nothing that can be done.
The problem is that the node-name is part of the URL and because two nodes can not have the same name that can currently not be done. We will work on making that possible soon but till then it simply does not work.
The only thing you can do for now, is to create the webhook having the nodeset to “GET” and then once it is confirmed you change it to “POST” and then save the workflow again.
Ahh thats unfortunate. Okay, will try your suggested workaround! Anyways, thank a lot for the quick help and have a nice evening! (also Berlin-based here )
well i am in a trouble…i completed the verification process with lead gen webhook but on testing the objects i am getting the same request and no payload…i don`t know what is going wrong…also i am not sure what should be the token value while verifying webhook… any help would be appreciated…
It appears that the FB Trigger node now has the ability to serve as the endpoint for both the FB verification request (which is a GET request) and event notifications (which is a POST request).