Refresh Token usage for Exact Online

Recently we have been getting a lot of trouble when trying to implement the API of Exact Online. We often get a response with a 401 error indicating there is something wrong with the refresh token.
I have contacted support of Exact and they indicated that the refresh token rules have been getting more strict lately.

This article shows how they plan to limit the usage of refresh tokens in the API, the literal answer I received was:

A token is valid for 600 seconds.
You can use the token for different calls and you don’t have to request a new token for every call.
Only when 570 seconds have passed can you reqeuest a new token with the refresh token.

In N8N I get a 401 error almost immediately. I can manually go to the ‘Credentials’ and obtain a new Access Token, however, when I perform the second request, it immediately seems to give me this error.

Could we please take a look at this?

Related topics:

Hey @laurens-novyx,

Do you think using the Wait node here will be helpful? If you can share more about your workflow design, I might be able to help better :slight_smile:

We just tested it again and it seems like the 401 error appears after 10 minutes. In the beginning, everything works fine, multiple requests in a row are not a problem.
Are we sure that N8N is able to receive the access token expiration time from the Exact response in the OAuth2-flow?

This is the JSON-format that Exact uses to provide an Access token

    "access_token": "xxx",
    "token_type": "bearer",
    "expires_in": "600",
    "refresh_token": "xxx"

Is the “expires_in” actively used by N8N to determine when to request a new refresh token?

We refresh the token when the API returns 401 unauthorized.

What version of n8n are you using?

We are currently using version 0.139.1
It seemed to have worked well for a while when we were on version 0.135.0 earlier.

I just saw this thread with the exact same problem.

We are also running on a version 0.139.1 on Docker.
(My flow, by the way, is only one ‘HTTP Request’ node.)

Given the solution in the thread mentioned above I tried this solution.

  1. Make two identical environments in version 0.139.1
  2. Keep the first one standard
  3. Use the environment variable N8N_USE_DEPRECATED_REQUEST_LIB=true on the second one.
  4. Both my SalesForce and Exact credentials expired on the first one after some time waiting, they were both still working on the environment with the environment variable configured.

Update of further testing:
I first waited until I had the error in the first environment, then I set the environment variable and restarted the n8n docker image, this fixed the problem automatically, without obtaining a new access token using the Credential configuration in n8n.


Sorry, I’m new to docker I’m not sure how to apply this setting a container and so I tried doing
docker run --env N8N_USE_DEPRECATED_REQUEST_LIB=true n8nio/n8n env
it created a new container but I can’t seem to start it up

Hey @ReMiKU,

Can you share the command you used earlier? You will have to append the new environment variable to it.

Hi @harshil1712,
I used docker run --env N8N_USE_DEPRECATED_REQUEST_LIB=true n8nio/n8n env and it created a new container but I can’t seem to start it so now I tweaked the command a little bit to this
docker run -it --name MikuAuto -p 5678:5678 -e N8N_USE_DEPRECATED_REQUEST_LIB=true n8nio/n8n:latest
Now I can start the container! but I have yet to test whether the credentials will expire or not. I hope they won’t ( > .<)

1 Like

The solution you provided works! so far couple of hours the credential didn’t expire! Thank you ( ^ .^)


Thanks @ReMiKU , that’s good to hear.

However, I think the use of a depricated request library is not something we would like in a production environment. Could one of the dev’s @harshil1712 @RicardoE105 take a look at this and maybe figure out what is going on in the latest request library?

Edit: I see they’re already doing that: Get Cookie After Login - #11 by jan

@laurens-novyx looking at the commits for 140 there are mentions of fixing tokens but given the 2 current options are to use the old library or to use the old version which uses the older library there isn’t really much of a choice for production environments at the moment.

There likely isn’t going to be anything wrong with the other library the newer one probably has more features available for the future.

@jan may have more info on the change.

Hey people.

Well what actually happened is that n8n was using the request library, which was deprecated.

We switched to another library on version 0.139.0 and tried to make it as compatible as possible with the previous one, but as you can see, some issues arose.

Yesterday we released version 0.140.0 with a fix for the refresh tokens issue, so I would recommend you upgrade and try running without the N8N_USE_DEPRECATED_REQUEST_LIB flag.

Also there are other issues I am working on now to fix other possible errors. Please bear with us as replacing an inner library unfortunately can have side effects but we’re working hard on fixing all issues.

I believe later today we will be releasing another hotfix (possibly version 0.140.1) with more fixes, so stay tuned :upside_down_face:


We updated to 0.140.0 and set the n8n_use_deprecated_quest_lib env variable to False. This resulted in the OAuth2 credentials working correctly. It seems like the fix in 0.140.0 has worked successfully.


We have updated to 0.141.1 yesterday and set the n8n_use_deprecated_quest_lib to false.
Unfortunately, we have received this error three times already since then:

The only thing resolving it is Reconnecting at the credentials section.

Hey @laurens-novyx

This is a strange scenario. This shouldn’t happen.

Is it possible that you have multiple instances of n8n running or perhaps multiple credentials for the same thing, such as multiple OAuth credentials created in n8n for the Exact?

This is something that might end up resulting in this, otherwise, I see no reason for this to happen, as I tested the refresh token flow for some apps and they’re working fine.