Some time ago, we changed the process of getting a Management APIv2 Token. This article explains what changed, why this was done, and how you can work around it (not recommended).

​
What changed and why

​
The user experience

Until recently, you could generate a Management APIv2 Token directly from the Explorer. You selected the scopes, according to the endpoint you wanted to invoke, and got a token from that same page. That way was very easy, but it was also very insecure. So we changed it. The new way uses the Client Credentials Flow. To learn how to use the new process, see Management API Access Tokens.

​
Why this changed

To generate the token, the Management API required access to your Global (used to sign the token). This is information that should not be exposed to web browsers. Furthermore, the API Explorer has no way to do authorization. This means that if a user could log in and access the API Explorer, they could generate a token with any scope, even if they were not allowed to have that scope. The new implementation does not pose such risks. Once you perform the initial configuration, you can get a token either by visiting the , or by making a simple POST request to the /oauth/token endpoint of our Authentication API. However, with regards to the manual process, we do understand that changing screens is not always the best user experience, so we are looking into ways to make the new flow more intuitive.

​
The validity period

With the previous flow, tokens never expired. With the new flow, all Management APIv2 tokens expire by default after 24 hours.

​
Why this changed

Having a token that never expires can be very risky, in case an attacker gets hold of it. If the token expires within a few hours, the attacker has only a small window of time in which to access your protected resources. To get a token, you should follow only the process described in Management API Access Tokens.