I have a workflow that is activated by changes to a Trello board. After triggering, it filters out events so that only a particular action (a card moving between two lists) is sent on to the rest of the workflow.
Sometimes when I restart n8n, this workflow fails to activate and gives this error message:
ERROR: Workflow could not be activated: 400 - "A webhook with that callback, model, and token already exists"
From what I understand, this is the error from the API call to Trello to set up a new webhook, which would then remain active and send events to the n8n workflow. It seems that after restarting n8n (such as after updating to a new release or updating packages on the server), n8n forgets it has a webhook already registered.
How does this work in the code?
- Does n8n request a new webhook each time the workflow is restarted? I
a. If so, does it make sure it has deleted the previous webhook when n8n is shutting down?
- Is it possible to re-use an existing webhook?
As a short-term workaround, I found that changing the name of the Trello Trigger node and saving/reactivating the workflow will register a new webhook that works, but this same issue eventually happens again after a few weeks.
EDIT: I’ve also been able to use the Trello API through Postman to look at the different webhooks registered, as well as go back and clean up the ones that n8n leaves behind.
Sorry to hear that you have problems!
This happens when n8n does not close down properly as it then does not clean up existing webhooks and so leaves them behind. n8n checks on startup if a webhook already exists (the ID gets saved automatically with the workflow) and if it does it does not, it creates it. According to the Trello API documentation, there is no way to request all existing webhook which is needed to do a proper check. Anyway, I just checked if there is an endpoint to do that, even though it is not documented in their API and there actually is. I just hope they do not remove it at some point (with not documented endpoints there is always the risk for that).
Anyway, I changed the code and this problem should not happen anymore once the new version got released. I will update here once it is out.
The endpoint is documented out of the “tokens” section of the API! I found it the first time this happened:
A GET request here with the right token and key returns a JSON array of all the active webhooks registered to a particular token.
Ah very interesting. They should probably change that. Would never have looked under tokens as they have their own “Webhooks” section and the identical “POST” one is documented there.
Anyway, is great to hear that it is there. So the risk that it stops working at some point is much lower.
Got released with [email protected]