(1) To delete your account, simply login, and select "Delete Account" tab on the lower left menu.

(2) Type in your full account email, and confirm the terms of deletion.

(3) Select the "Delete" button.

Once completed - you will be logged out, and any information we have collected will be permanently deleted.

• North America: 1 KM
• Europe: 1-6 KM
• Other areas: 9-13 KM

We recommend avoiding usage these station ID's by either using another query method (lat/lon, postal code, city ID) or using a station from our published   "stable" station ID list on the API metadata page.

Querying by station ID is functionally equivalent to querying the API with the lat/lon of the station. For example the two requests are equivalent:

http://api.weatherbit.io/v2.0/current?station=KRDU&key=YOUR_API_KEY

http://api.weatherbit.io/v2.0/current?lat=35.88&lon=-78.79&key=YOUR_API_KEY

Ground truth (station data) is always preferred in a response. As the distance from the requested point, and nearby available station data increases - other available data-sources (ie. the ERA-5 re-analysis) will be preferred. Additionally, the quality of the nearby station will impact whether it is used. Stations with significant issues, or missing observations are excluded.

As a result of this functionality our API provides one of the only multi-source historical weather datasets on the market by combining the advantages of spatially complete gridded datasets with station data.

These advantages include:

• Global coverage - even in remote areas, and over open water at a 1-13 KM spatial resolution.
• Improved accuracy in most areas due to assimilation of non-station observations (such as radiosondes, airplane observations, satellite estimations, ground radar, etc.)
• Excellent quality control.
• Temporal completeness (minimal missing data)

Most providers of weather data use only station data. As such the differences between our API, and others will likely be significant in areas of poor station coverage.

• Weather station data (hourly / sub-hourly reporting)
• NOAA Real-Time Mesoscale Analysis (RTMA)
• Ground based weather radars
• NASA IMERG (Global precipitation estimations)
• ERA-5 Re-analysis
• GLDAS Re-analysis
• CAMS Re-analysis
• GHCN (daily reporting stations)
• Global satellite data
• Air quality stations
• And more...

You may use the "revision_status", and "revision_version" fields to determine whether or not you will need to retrieve updated data at a later date.

The "revision_status" field will return "interim" for data still awaiting updates, and "final" for data that has been finalized such that it is considered the highest quality currently available. Most historical endpoints reach this final state within 10 days.

To ensure our service always returns the best possible data for every location - on rare occasions - it is necessary to make changes to either calculated fields, or the underlying data (even when in a "final" state). In this case the "revision_version" field will indicate an updated version number.

revision_version: "MAJOR_VERSION.MINOR_VERSION" - Example: "1.0"

The minor version will update when:

• Improvements have been made to calculations of derived fields.
• Bug fixes or minor improvements have been made that may only impact specific locations or time frames.

The major version will update when:

• There are new historical dataset(s) added.
• Major updates to station/data source selection have been made.
• Changes or fixes have been made that impact all data returned by the API.

In general, revision_status = "final" data is considered high the highest quality data currently available. It will be suitable for scientific research, and most business needs.

However, if your use case is such that you must constantly maintain the highest quality data in a locally hosted database, then we recommend also periodically checking for the revision_version updates.

Example:

{
   "city_id":"4161685",
   "city_name":"Lawtey",
   "country_code":"US",
   "data":[
      {
         "clouds":50,
         "datetime":"2022-11-12",
         "dewpt":65.8,
         ...,
         "revision_status":"final",
         "revision_version": "1.1",
         ...
      }
   ],
   "lat":30.149230998969,
   "lon":-82.01068631381,
   "sources":[
      "722067-63823",
      "US1FLCY0040",
      "US1FLCY0012",
      "US1FLCY0009",
      "imerg",
      "merra2",
      "era5",
      "modis"
   ],
   "state_code":"FL",
   "station_id":"722067-63823",
   "timezone":"America/New_York"
}

{
   "city_id":"4161685",
   "city_name":"Lawtey",
   "country_code":"US",
   "data":[
      {
         "clouds":67,
         "datetime":"2022-11-21",
         ...,
         "revision_status":"interim",
         "revision_version": "0.0",
         ...
      }
   ],
   "lat":30.149230998969,
   "lon":-82.01068631381,
   "sources":[
      "722067-63823",
      "US1FLCY0040",
      "US1FLCY0012",
      "US1FLCY0009",
      "imerg",
      "merra2",
      "era5",
      "modis"
   ],
   "state_code":"FL",
   "station_id":"722067-63823",
   "timezone":"America/New_York"
}

To get only the revision_version value without querying for historical data, you can simply use the Historical Revision Version API.

https://api.weatherbit.io/v2.0/history/revision_version?key=YOUR_API_KEY

Which will return JSON like:

{
  "revision_version": "1.0"
}

For example, if you are enrolled in the "Business" plan, and want to retrieve hourly historical data for 2017 for a single location, you simply need make 12 total API requests (1 month per call limit).

Example: Retrieve all hourly data for 2017 for one location (35.5, -75.5).

# First request
https://api.weatherbit.io/v2.0/history/hourly?lat=35.5&lon=-75.5&key=<API_KEY>&start_date=2017-01-01&end_date=2017-02-01

# Second request
https://api.weatherbit.io/v2.0/history/hourly?lat=35.5&lon=-75.5&key=<API_KEY>&start_date=2017-02-01&end_date=2017-03-01
    
...
    
# Last request
https://api.weatherbit.io/v2.0/history/hourly?lat=35.5&lon=-75.5&key=<API_KEY>&start_date=2017-12-01&end_date=2018-01-01
    

• For the best performance when retrieving a large amount of data for many locations: Break up any large request into smaller parts. For example, instead of retrieving one year of data per request - retrieve only 1 month per request.
• In general, our historical data servers are better optimized to handle many small requests, rather than singular large requests. Smaller concurrent requests are preferred to fewer large requests. However, keep in mind the req/second limitations of your subscription.
• Add http request retry logic to any long-running script. Preferably with an exponential backoff algorithm.
• Alternatively, use the Historical Data Custom Order System in the dashboard (note: this service is invoiced separately).