I was doing some testing with the above API key, and I was able to get observation data (not just meta data) from station 28974, which is sharing data publicly.
As I understood the policy, only owners of the stations should have access to that data.
Is this api_key some master key? This looks like a bug to me.
From the API page:
During development and for any use that is strictly personal (one user, yourself), use this development API key:
the owner made it public data! what is the problem being able to access it??
Look at the policy on this page:
Iām not sure this is a bug, but youāre right that it seems inconsistent with the Data Access Policy. The development key behaves at an Enterprise level rather than a Normal level. I assume this is so applications can be easily tested at an Enterprise level. There is a usage limit though. I have seen the development API key fail because of too many concurrent requests/connections
according to the policies on this page, āany userā should not have access to observation data of both public and private stations.
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.
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:
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.