We’ve just rebranded and updated the Tempest API docs:
The most significant change is a shift from the “API key” concept to the “access token” concept for authentication. The API key concept still exists, but only for Enterprise apps (which are a tiny minority of all apps) - the vast majority of apps out there do not need an API key.
The preferred authentication approach for third-party apps is Oauth2, which is now publicly documented here with the personal access token as an option for apps that can’t support Oauth2. The “developer API key” will continue to operate through the end of 2020, but if you are using it, please migrate to one of the “access token” methods as soon as possible.
The Remote Data Access Policy has been updated a bit as well, and includes a description of how forecast data fits in with that policy. The forecast API endpoints have not been documented yet, but that is coming soon.
Short answer, yes. The PAT is intended for personal use, testing and locally-hosted scripts & integrations that don’t have a UI that’s conducive to Oauth2 (that is, no way to access the Oauth2 authentication screens). But the PAT will work in any app.
The main advantages of Oauth2 to your app or integration are: (1) it’s simpler for your users to authenticate, (2) you look like a more professional developer and (3) you’ll have more and better analytics for your app (not available yet, but on the road map).
What about API keys that were granted originally? I’m assuming those are Enterprise level keys but I don’t believe any partnership agreement was ever made for those. Should I be moving my programs to use personal API tokens instead?
I’m mostly confused by Oauth2, but I think that’s because I don’t work on mobile or web “apps” All of my programming is for automation plug-ins that many times don’t even have a their own UI, just a method of transferring configuration parameters from the framework’s UI to the plug-in.
Yes, your API key is actually not an “enterprise” key (no special powers) and you should start using the personal access token approach as soon as practical. No huge rush - we’ll keep your API key active until you can make the transition.
Anyone else using the developer API key or a special (non-enterprise) API key should do the same. We will reach out to you individually after a while if necessary.
If there’s no UI then there’s no need to implement Oauth2. Just add the personal access token as another configuration parameter.
Now, there’s a small twist that applies to those of you who have been issued an API key already. We have not documented this yet, but there are actually two options:
stop using your API key and replace it with Oauth2 or the PAT method instead.
continue using your API key and add Oauth2 or the PAT method. The API key won’t be used for authentication, but it will set you up for future analytics data that’s on our road map, as mentioned above.
Are the formulas for derived metrics (and other info) going to make a return? It looks like those links now just redirect to the ‘front page’ of the API / OAuth information.
and (3) you’ll have more and better analytics for your app (not available yet, but on the road map).