Unable to pass Slack's URL verification for the Events API

Describe the issue/error/question

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.

Same issue as this thread.

What is the error message (if any)?

(Borrowed from the thread linked above)

Please share the workflow

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 0.201.0
  • Database you’re using (default: SQLite): SQLite
  • Running n8n with the execution process [own(default), main]: own
  • Running n8n via [Docker, npm, n8n.cloud, desktop app]: Docker

Hey @Wouter0100,

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? :smiley:

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.

But I do not know why Slack is retrying, nor why they’re unable to show a proper error besides “Hmm, something’s gone wrong.”.

Here you see Slack retry:

Hey @Wouter0100,

That is a bit odd, If you check the execution for your workflow is it returning ok from the respond node?

Yes, it is. Also manually calling the URL via curl works.

Sounds like it could be worth asking Slack everything sounds like it is all good on our end.

Thanks thus far, I have send a ticket to Slack. Let’s see what they reply.

Any updates on this one please?
I have exactly the same problem.

Hey @kp-kun-dip,

Welcome to the community :raised_hands:

Can you share the workflow you are trying, how you have n8n installed and what version of n8n you are using?

At the moment this process is still working on my instances.

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.


Hey @kp-kun-dip,

I have just given your workflow a test as it is and it has worked for a test execution.

If I then set the workflow to active rather than a test run and update the URL it is also working.

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.

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.

Hey @kp-kun-dip,

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

1 Like

Solved by changing Execution Process to main!
Thanks a lot!


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.