Hello everyone,
I tried everything for a api refresh; but seems to not work.
in the api Connector it work, I tried json, raw it both work but once i put it in a API BACKEND it doesn’t work, and I already put 2 days on that, no idea what’’s going on.
cIwhy don’t you use user agent auth instead of custom?
Did you check for privacy rules issue?
Hi Tamourpro, I have just submitted a proposal on your Job Application via upwork. You can respond to it and we move things from there in solving the fixes.
Hello @tamourpro
Can we jump on a call to investigate this together? to see if my thoughts will apply.
Can you see what value is passed in refresh_token in server logs?
Does it have a error?
This is a common issue when API calls work in the connector but not in backend workflows. Here are the most common causes:
The API call is set to “Use as Action” instead of “Use as Data”. For backend workflows, you usually need to set it as Action. Check this setting in your API Connector.
Privacy rules might be blocking the data you are trying to access. Backend workflows run with admin privileges, but the data source you are referencing (like API_Configs first items TTLock_Refresh) might have privacy rules preventing access.
The refresh_token value might be empty when the backend workflow runs. Check the server logs to see what value is actually being passed.
Timing issue - if you are trying to use a token that was just saved, make sure the save action has completed before the API call runs. Add a short pause or use “result of step X” to ensure proper sequencing.
The API endpoint might require specific headers or authentication that works differently when called from the server vs the browser.
To debug this:
The server logs will show you exactly what data is being sent and what error TTLock is returning.
@amjad 1 and 5 are false.
Thanks for the correction @Jici. You’re right, I missed that the API was already set to Action in the screenshot, so point 1 doesn’t apply here. And point 5 about server vs browser authentication differences isn’t relevant for this TTlock API case. I appreciate you pointing that out.
