There doesn’t seem to be a lot of documentation around OAuth and the process aside from the Javascript example which is fairly barebones.
I’m able to successfully retrieve an access token but the /v1/auth/oauthtoken endpoint seems to only return an access token but no refresh token. If I hit the /v1/auth/renewaccesstoken endpoint it seems to give me both an accessToken and a mdAccessToken. However the docs don’t mention anything about a mdAccessToken, and hitting the route with an expired token doesn’t seem to work.
I’m trying to run my bot headless and would like to be authenticated at all times. What is the preferred way to ensure that my tokens are always valid? Do I need to schedule a renewal task to renew the token right before it expires? What is the purpose of the mdAccessToken?
renewAccessToken is the way to go. Typically I use a timed loop that just runs some checks after a certain amount of time has passed (mine literally checks every second). Most recently, I’m using an RXJS interval observable to perform this task. I use this time check to figure out if the market is closed or if my access token is expiring soon. Just make sure you renew the token before expires_in from the OAuth response or expirationTime from the renewAccessToken response. It seems to work fine firing it ~30 secs before expiration.
Regarding mdAccessToken - this is only here for backward compatibility of the Trader application, you can rely on accessToken alone for all operations that need a token.
Thanks a lot. I ended up creating a task scheduler that can schedule a renew on new token as well as server start. Now a follow up question is I have two OAuth apps registered, one for development / staging, and one for production. Is it possible to use the same access token to connect with both the production app and development app simultaneously? What is the preferred method to handle multiple environments?
There already are two environments by which the API is separated - the demo and live variants use the simulator and live markets respectively. They work in exactly the same way so you can easily migrate from the demo environment to the live environment by simply changing your base URL. If you separate your environments using our demo or live API namespaces, you would be able to use the same API Key to access both environments interchangeably.
If that doesn’t suit your needs, please explain what else you would need the development environment for and I will see what I can find out for you.
So the production environment will have a different url which means i cannot share the same API key since it uses redirect_uri as one of its identifiers. But what you said is what im planning on doing - having development connect to demo only. The only difference is that I’ll be hosting it on a separate vps, so i can catch issues for new features without breaking a working bot.
Ah I see what you mean. You could use a private repository and fork your updates on a patch branch. You could run the forked code/patch branch on just the simulator, then merge to the main branch when your patch is ready. You could have your production bot running off the GitHub repo’s main branch headlessly using some kind of hosting service. You could even run your patch branch headlessly that way if you’re going for a full-automation approach.
To run both apps at once you’d need to purchase a subscription for a second active connection. And if you really wanted them to communicate, you could probably write some kind of middleware application, forward messages from both bot apps to that middleware app, and then use that app to sort out messages from prod/dev combined, or at least log errors and other events. I’m not sure 100% how you’d accomplish it in practice, but it seems possible.
They do not need to communicate with each other, I only need the staging one to run without errors before promoting to production. I have already purchased as second connection for use with TradingView, would I need to purchase additional connection?