OAuth Token not refreshing for GraphQL credential because API returns a 200 with a nested error

[NealSr]

Describe the problem/error/question

We have a GraphQL API that uses OAuth 2 for authentication and when the JWT token expires, the API returns a 200 with a nested error message. e.g.

Status: 200 OK / Body: {"Errors":[{"message":"Token verification failed: jwt expired","path":["path"],"statusCode":401}}],"data":{"path":null}}

I learned a while back that n8n expects a 401 when a token expires, so it can auto-renew the credential.

My question is: for GraphQL APIs specifically, the practice we use is to return a 200 with a nested error message because the call itself was successfully rejected. We would only return a 200 or a 5xx in general. Is there a way to identify a credential as a GraphQL credential so it can check that error message? If not, how difficult is it to create a ‘custom’ credential type on our end that would do that?

What is the error message (if any)?

JWT Token Expired (after 60 minutes)

Please share your workflow

1. Create a credential and authenticate against our OAuth Server. (Authorization Code Type)
2. Create a workflow that uses the credential
3. Execute the workflow successfully for the initial token timeout period (60 min in my case)
4. Workflow begins to error out due to JWT token expired after that time.

Information on your n8n setup

• n8n version: 1.52.2
• Database (default: SQLite): SQLite
• n8n EXECUTIONS_PROCESS setting (default: own, main): main
• Running n8n via (Docker, npm, n8n cloud, desktop app): Docker
• Operating system: Linux/Ubuntu
  edit: corrected n8n setup formatting.

[n8n]

It looks like your topic is missing some important information. Could you provide the following if applicable.

• n8n version:
• Database (default: SQLite):
• n8n EXECUTIONS_PROCESS setting (default: own, main):
• Running n8n via (Docker, npm, n8n cloud, desktop app):
• Operating system:

[NealSr]

I’ve updated the post with correct formatting on the n8n setup section.

[Jon]

Hey @NealSr,

We don’t have anything built in to handle that, We would always expect the response to be a 401 on an auth failure even with GraphQL. The best I can think of would be to manually handle the auth process in a worklfow unless you wanted to make a worklfow to handle getting the auth token and call that when the error occurs.

[NealSr]

Thanks for the feedback Jon - We were able to find a work-around where we call our REST api first, which does return a standard 401, then we call the GraphQL second, and the credential behaves itself with the REST call.

Internally we had some discussion on whether Graph APIs should return nested errors or not, but we are going to hold off on changing things since we’ve *finally found the root issue.