I am working with an API that requires to pass an authorization token in the header of each call. The token expires every hour and gets refreshed with a refresh token. The newly refreshed token needs to be passed in the header with subsequent calls. Is there a way to make the token dynamic in the header so that it can be changed frequently instead of hard coded?
Thanks to @ambroisedlg for the help on this one. He showed me how to pass a dynamic token in the API Connector to handle refresh tokens that change on a regular basis. For the benefit of others looking to do this, I’ll write the solution here:
When you’re setting up the call in the API Connector plugin, you can add an Authorization key in the header, but you’ll uncheck the “private” checkbox. Unchecking this private checkbox allows the value to be dynamic. You’ll need to have a value in this field in order to initialize the call, but if you use a dynamic value in your app, that dynamic value will override the value in the plugin setup used to initialize. See image below how the private box is unchecked. You can see also that the value is empty. it can’t be empty when initializing. You can leave the value there even after initializing, but the dynamic value will override it.
This other image below shows how when you uncheck the private checkbox, It shows a place in the editor to add the Authorization header value dynamically. So when it calls the API to get the data, it uses this dynamic token value (which refreshes on the API every 60 minutes). For testing i was pulling the token from the database, but I ended up saving it as a cookie and pulling it from there.
@duke.severn @cs1
9 Likes
@robertpbrinton This is super, thank you! As your keys change every 60 mins, and I assume only the current user - the one the key is made for - can see this. This might be “safe enough”. I do want to leave here for posterity that doing this with your Private Keys (especially long-term or any shared key) is not recommended, as you are potentially exposing your keys client side to anyone who has access to that workflow.
yes, the token is only for the current user. Each user gets their own tokens. the original token is received once the user logs in using email and password. that token is stored in the browser as a cookie and the cookie expires after a period of time. If the cookie expires after a period before the refresh token is used to get a new one, the user will be required to enter username and password again to login and receive a new token.
2 Likes
Thanks for the solution. I was able to see the dynamic option to fill out the rest of the header. I noticed that you stored the tokens in cookie and pulled them from there. Can you please let me know how you did it? Thanks in advance!
Hey! yes, i store the token in a cookie. I use a plugin called Cookie Handler. this has a workflow action to “write cookie”. and then there is an element for reading the value from the cookie. so when I do the API call, for the token value i use a dynamic value to use the cookie reader’s value. If you can’t figure it out, i can make a video that provides more detail.
1 Like
Thank you for replying back! I found the cookie handler plugin and was stuck on using the cookie reader. It seems you can set up the key on that cookie reader element in the design section, as well as in the workflow, but I am not sure how to do to in the correct way. Could you please show me?
Here’s a video showing how I did it: http://somup.com/cYXfD7Iq0r
2 Likes
Hi @robertpbrinton,
Thank you so much! The instruction is crystal clear in that video. You are a life saver!
No problem! I have used the forum a lot to find my own answers, and I’m happy to contribute back to the community this time 
1 Like
For the life of me, I can not figure out how to find this in the workflow 
Can you clarify what part you are trying to find in the workflow?
Hi there, I am trying to make a call with method POST and a dynamic token
but when I initialize the call show me this response
Could you please help me?
1 Like
Are you putting the authorization token after the word Bearer? Can you share the post endpoint that you blocked out? That should be able to be shared, it’s public.
Hmm that looks good to me. Are there any other headers needed in the documentation? Sometimes it needs a header for Content Type. Maybe share the link to the documentation.
Yup Content-Type application/json but it doesn’t work yet
and this is the documentation:
https://docs.getmati.com/#post-2-create-verification
https://www.postman.com/mati-team/workspace/warped-comet-3756-s-public-workspace/documentation/6584856-6453aa5f-a739-48e7-9a86-6d90fff7ade0
How is your payload body formatted?
Missing the flowID?