I’m unable to pass the URL verification required by the Events API, as described here.
I tried the json and text response (also by forcefully setting the Content-Type to text/plain for text, as this was different in N8N’s text response for the Respond to Webhook node).
I curl’ed the request myself to see if the request was responding correct, and it was - the only different being that n8n returns 200 and not 200 OK. Especially because Slack says the request URL responded with a HTTP error, it seems it’s parsing the response code.
Thanks for opening the new thread, The workflow I use for the Events API is below, Don’t forget if you are using the webhook-test url it will only run if you have pressed the Execute Workflow button.
Thanks for your response. I honestly do not see the difference between yours and mine?
It seems to be exactly the same, the only difference being that I use the item’s value in Respond to Webhook instead of referencing to the first node. And, the webhook URL is different.
I fully recreated yours now, but there is no behavioural difference:
and the Respond URL verification still shows the correct challenge:
Besides the above, I think I now know partially what is going on, but not sure why: it seems Slack is retrying the URL verification hook. That is why with the webhook-test it fails with a HTTP error (because the second try it fails as the workflow not being executed). With webhook it seems to retry 3 times and then fail with the error below.
I observed this behaviour as well in my testing, but forgot to mention.
Attaching the workflow below.
n8n is running on self hosted AWS container.
n8n version: 0.220.0
I have checked the response of this webhook on POSTMAN using mock request data which I copied from slack. The mock response is in correct format.
Somehow, slack says it’s not ok.
I was unfortunately unable to get this working. The Slack support was so much back-and-forth that I eventually gave up, as they did not seem to ack the problem.
Eventually dropped n8n in favor, our own written, Golang bot.
I suspect this is going to be something local to your setup, What execution mode are you using (main or own), It could be worth trying main to see if that makes any difference.
@Jon
Wow thanks! Your Request and Response looks exactly the same as mine.
I suspect this is going to be something local to your setup, What execution mode are you using (main or own), It could be worth trying main to see if that makes any difference.
Can you explain what “main” or “own” is? I tried running on both test execution, making it active and using production URl as well. Both fail.
We have 2 Execution Process options, Main and Own. The default is own which can be a bit slower depending on hardware / resources which will create a new thread for the workflow so if Slack is calling it might take up to 3 seconds for the workflow to fire up. If you set EXECUTIONS_PROCESS to main though it will run all the workflows in the same process and will be a lot quicker.
For my setup it doesn’t matter which option I use but it could be that for AWS main is the option to go with for a quicker response, You can read about both options here: Execution modes and processes - n8n Documentation
