With the development key, you cannot access data of any private station.
However, as stated in the API documentation… the development key allows access to observation data of public stations, but WILL be shut down in the near future.
With the development key, you cannot access data of any private station.
yep… inconsistent… so needs to be clarified.
True… I’ve set a station to “private” and then tried to access it with the key and was unable to.
There is two things going on here.
First, a station marked as private cannot be accessed by anyone except the station owner. That’s clear.
Second, all public stations can be accessed via the API. At a Normal level any individual owner can access their data from their station. This access is free and is controlled by the Private Access Token/OAuth. If you want to access data from stations you don’t own, however, you have to enter into an Enterprise agreement with WeatherFlow. This costs $$$.
At the moment the development API key remains an Enterprise level key. However, this will very likely change in the future as indicated by:
- Please be aware that rights to data access my be revoked at any time for any reason. This may include, but not limited to, the number of stations accessible per key, frequency of requests, and volume of data.
Not a “bug” per se… but rather a “cart before the horse” situation. WF implemented the dev key before setting the data access policy, in an effort to jumpstart user development.
I have chatted with @dsj about this and the Dev Key access will be modified in the near future as WF starts fully implementing the OAuth functionality. Which is the main reason for the btstWx reconfigure…
Thanks for the question, @johnny.a.fernandes. We are long overdue for an update to our docs, but I promise we’re making progress!
The info provided by @peter and @btst.online is correct. The development API key has been around since the first version of our API and was included to give users a simple way to get started, but it was never intended to be used in a production environment. It has volume restrictions and will be deprecated soon. The next update to the API documentation will be consistent with the data access policy, and will focus on the access token concept, which will be the normal way developers will interface with the API (with an API key only required for “enterprise” users).
And don’t worry: we will give folks plenty of time to update code before the dev key stops working!
Thanks! I’ve been talking to Keith Koenig at WF… he’ll be able to tell you why I’m asking about this.
Anyway, I’ve gone ahead and created a token for myself to access my station(s)… seems to be working as expected.
The ‘share publicly’ setting in the app indicates that the station owner has given permission for WeatherFlow to share data that their station uploads publicly through WeatherFlow/Tempest apps. But access to data by third-parties via the API is still bound by the data access policy.
I have a suggestion. Since people will have to create their own tokens, when you send people to “https://tempestwx.com/settings/tokens” and they are not logged in, the log in page should redirect them back to it once they log in successfully.
I’m working on a product that is going to be dependent on the API Key generation process. I have a help me page with a link to the user’s token generation site and as @93ben points out the link is lost if the user has to login. I second ben’s request to keep the link when having to login.
Here are a few more suggestions / questions:
- Would it be possible to add a copy button to a key that has already been created as you do for a new key?
- It seems to take a very long time for a new token to become valid in the system. Will this be improved? Is there a way my app can test for a valid token while the system is adopting it? I would like to give the user feedback right away when they type in a new token.
- Is there a way I can generate the token programmatically if I prompt for the user’s login ID and Password that will work around these issues? (I prefer to not do it this way but will if it is the only choice).
Thanks for all the great work on your API!! I can make what you have work just though I would chime in.
It’s really simple with the REST API, it returns this JSON array…
All you would need is that 401 code and that would tell you if the token is invalid.
@jhrucker to add on that if the user has a valid token but the station doesn’t exist under that user it produces a 404 error.
Maybe I wasn’t clear. I know how to determine if the token is not valid that is not the problem. The problem is when a user generates a new valid token and types it in or cuts and pastes it into my app I have no way of letting the user know they have correctly typed it in. The token is not valid for several minutes. If I make a call with the “new token” it comes back with an error. However, if I wait a few minutes and make the call it is valid.
That’s odd because when I type the token in, it’s already valid just after I create it.
You could do a preg_match with the token…
I haven’t noticed this. I just generated a new key and it worked immediately (and when the key is deleted it ceases working immediately).
Yes there is a way to do it programmatically, but it is not as simple as requesting the username and password. You have to use an OAuth2 flow and have the user directed to the WeatherFlow servers to login and authorise access. Details here: https://weatherflow.github.io/Tempest/api/oauth.html
Boy that would be awesome if I was seeing the same thing. It is consistently not working that way for me. In fact if I delete a token my app can still use it for hours after. My app keeps polling the API every five minutes I wonder if that is keeping some type of session open your not seeing. Let me turn on all my logging and see if I’m missing something on my side. Maybe my post token deleted api calls are skipping over a connection error and I’m pulling down stale data but think it is current. I doubt it but will look.
I will take a look at that. Thanks!!
I have my logging turned up and I can still make calls to the API after I have deleted the API Key on the web site. I can make calls and I’m getting updated data. I have even closed the session and restarted my node.js app and I can still make calls to the API with the deleted key. This is what I have seen in the past. I expect I will be able to make calls for a few hours then it will stop working.
Almost looks like there is some type of caching going on with the key. I’m in downstate Illinois, USA. Anybody else seeing these type of delays?? If Amazon is hosting their API I wonder if it is a region thing??
I have been following your thread and I love it!
We agree with you and Ben: any page that requires authentication should redirect you back to that page following successfully authentication. We’ll get that taken care of soon.
Possible for sure. We’'ll consider adding it - thanks for the suggestion.
That is definitely not how it’s supposed to work - it should be instant. However, your report prompted us to look and we’ve discovered an issue that is causing up to a one-minute delay before a new personal access token becomes active. We’ll put that on the bug list and get a fix into a future API release.
Ah, now we’re getting to the crux of your issue. What you’re describing is exactly why Oauth2 exists - it allows you to generate a token automatically, seamlessly. It’s the way our third-party integrations work (Amazon Alexa, Google Home, Samsung Smartthings, IFTTT) . It is by far a better solution for an app like yours compared to using personal access token. As @peter mentioned, it’s a little more work but it will provide a MUCH better user experience.
And thanks to you for reaching out and for this very cool application of the Tempest System! We are happy to support these kind of projects!
Thanks David I’m off and running on the OAuth process. I have started a post over here in the “oauth2-access-token thread” as I think that thread’s topic is more appropriate for my questions on OAuth.
Thanks for all the great support!!