Issues with HTTP Connection & Token Refresh

Integrator.io
, ,
1

Hi There,
I'm working on a project with a system called Opendock.
Warehouses | Opendock APIs

There's sparce documentation on authentication. They have a POST operation that takes a user and password body and returns a token. The token is valid for three days.
There's a GET operation that uses the existing token and returns a new one. The issue seems to be, once the system returns a 401 and triggers celigo to attempt the refresh, the refresh fails since the token is expired.

I seem to need to force the refresh every couple of days and not wait for a 401.

Any ideas here? Maybe use the refresh to get the new token and use the Celigo API to update the token in the connection object??

Thanks!!

2

We've seen similar behavior before, and it doesn’t align well with how our connections handle token refreshes. By default, we assume the existing token is valid until a 401 error occurs, which then triggers the refresh. However, in this case, since the token expires before the refresh attempt, the process fails.

Existing Approach

One way to handle this is to create a flow that runs once a day (or every other day) to proactively fetch a new token and update the connection object via the Celigo API. This ensures the token remains valid, though the downside is that the new token would be visible in plain text within the flow.

Alternative Idea (a theory I have not tried yet)

You could try setting up a flow where an export step gives you a dummy record, followed by a lookup step that makes a GET request to the Opendock API. In the lookup step’s headers, add an additional Authorization header with a value of Bearer dummyValue. This might trigger a 401 error (though I'm not sure whether the connection-level or import-level Authorization header would take precedence), forcing the refresh. If this works, you could also add a preSavePage script to suppress the error from appearing in the UI. This approach would prevent tokens from being exposed in plain text.

3

Hey Tyler!!
Thank you for the suggestions. I'll give option 2 a shot and see how it goes. I'll report back here how it goes.

Should I put in a feature request to support tokens with timeouts??

4

No need to submit a feature request — I’ve already added this as an insight to an existing backlog item that’s meant to address this. It’s only come up once before, but one idea I've considered as a lighter-weight solution is to expose a connection-level API that can manually trigger the token refresh. That way, you could build a flow to hit that endpoint when needed. I hesitate to bake this directly into the connector, since it could be misused in situations where the native refresh logic would work better and be more efficient.

1 Like
5

Hey Tyler,
I've confirmed that you theory works.

The extra authorization header did cause the api call to throw a 401 error and trigger the refresh.

Here's the connection log from the call.
{"url":"https://neutron.opendock.com/auth/me","method":"GET","headers":{"Authorization":"Bearer ********","authorization":"dummytoken","accept":"application/json"}}

You can see there are two authorization headers.

I do like your idea about having a /refresh endpoint for https connections where we could manually trigger the refresh.

For now, this seems to be keeping the connection alive. I'm triggering the flow once per day.

1 Like
6

I love it when a theory works out. Thanks for confirming!

1 Like