Thanks for the update. I’m trying some things as well. First I thought maybe it was a simultaneous sync on the same webhook which possibly invalidates the refresh token (in your logs the problem also happens on the same second). But today it still invalidated even though the hook was only called once.
I was looking at this mode as well. We will implement it in our docker setup if it fixes the problem on your end.
Im sending a simple request to Exact now every 5 minutes to see if that does anything. Maybe it can’t handle a long time between calls. Don’t expect that will fix anything. But we’ll see.
The source code is available so you can check the auth there if you want to replicate it in an http request node.
What I know is that Exact and their Oauth2 implementation is a bit annoying. I do not remember the exact details for how long a refresh token stays valid but it should be long enough for standard syncing.
That is very odd. I use the node myself and do not run into the same issue.
Looking at the error the refresh is happening in a wrong way. Exact Online is very fussy about stuff.
Are you running multiple workflows at the same time using the Exact Online API? This could cause a race condition where you try to refresh the token while another flow is also doing the same.
I suspect the issue is being caused by the StockPositions webhook. When a single order contains multiple products, the webhook seems to trigger for all of them simultaneously. I’m currently testing with queue mode enabled to see if that resolves the problem.
So far it is working fine but I just want to make sure before marking it as a solution.
Ah, yeah then it will be the webhooks coming in at the same time that messes it up when the refresh happens.
n8n queue mode will not help with solving that.
I would push everything to an actual queue like rabbitmq and then process them one by one from there. Can also use Redis or something else, but the RabbitMQ native nodes provide all needed functionality.
It does seem to help because it not caused by the webhook itself but by the call that is made to exact right after here. So far it seems that my problem is solved @pauljunior.
This is what my workflow looks like @BramKn (I added the wait node to add a delay in between the webhook requests)