Cannot create a webhook on some third party service

[afu-dev]

Hello,

Today I tried to create a webhook for Trello with the construct available in Lift. But I stumbled across an error saying that the webhook was not returning a 2xx response code. After some testing, I found out that Trello was sending a GET request on the endpoint to check its availability.

Yes, it's weird to check the provided endpoint with a GET request when all other requests will be POST. But anyway, my solution was:

• create a Lambda in my serverless.yml ;
• manually attach it to the HttpApi created by Lift (on the same route, but with the GET method) ;
• create the integration on Trello API with the webhook endpoint ;
• delete the GET route ;
• remove the Lambda from serverless.yml.

A bit painful, but it worked. I wonder if anyone got the same problem with another third party service? Maybe it's just this tool that does a wrong check and I need to inform Trello/Atlassian? Maybe Lift can add an integration on GET and HEAD routes in addition to the POST one?

(This is open to discussion and could have been a discussion thread in the Webhook RFC or other, but because I couldn't use the Webhook Construct for Trello without some manual tweaks, I prefer to create an issue)

[t-richard]

I've seen this several times, I know Mandrill does it but will eventually fallback to a POST request if the Head is failing

Your webhook callback URL should be set up to accept POST requests at a minimum. When you provide the URL where you want Mailchimp to POST the event data, a HEAD request will be sent to the URL to check that it exists.

If the URL doesn't exist or returns something other than a 200 HTTP response to the HEAD request, Mailchimp will fall back and attempt a POST request.

[mnapoli]

That's super interesting, thanks for the details. I'm not sure if @fredericbarthelet has ideas, but hopefully we would be able to support those cases without implementing too many specific things.

Would it be enough to support GET requests (on top of POST)? Or do we need a different behavior (for example does GET has the headers to validate the webhook?)

Another approach could be: if we were using the default API Gateway (not creating a new one), then users could do anything, including adding a GET /webhook route manually. (I'm afraid of having many different scenarios for each provider)

[fredericbarthelet]

@Chtiadrien thanks for reporting this issue :) At the moment, we can always implement this health check route by default in the construct without any additional parameters allowing its configuration (so a GET and HEAD endpoint on the same path with a 200 OK response without any check). This would prevent the construct config from being too complicated.

We could always have this conversation again in the future if new health check protocoles surface. WDYT @mnapoli ?

[mnapoli]

I'm afraid of webhooks that might work via GET, any idea if this is common?

[fredericbarthelet]

@mnapoli not aware of any 3rd party actually using GET as a webhook method. This issue relates to GET being used as a healthcheck at webhook creation, followed by normal POST on the endpoint whenever hooks are triggered.