"See bottom for general descriptive information. --- # Releases ## [1.9.0] 2025-12-17 ### Add parameterization to auth requests * authorization URL now defined by variable set for environment ## [1.7.4] 2025-07-01 ### Add WMO code strings to supplement the wx code values that have split the original report * Up to 4 wmoCode fields may be present in response * E.g., case with `wx1=VC`, `wx2=TS`, and `wx3=RA` from `rawTxt` containing `...VCTS RA...` will have `wmoCode1=VCTS` and `wmoCode2=RA` * Only fields with values are included in responses ## [1.7.3] 2025-06-05 ### Revise handling of ceiling and cloud layer data * Change to only include cloud layer as ceilingLow, ceilingMid, or ceilingHigh if \"BKN\", \"OVC\", or \"VV\" * Add new cloudLayer fields as applicable * Up to 6 cloudLayer fields may be present in response * For any cloud layer, whether ceiling or not ### Add constraints to temporal parameter values * make request fail if parameter is set to something that would obviously not correspond to available data * are sanity checks, as still possible to specify time values for which data cannot be provided ### Add wx code and RVR data to responses as applicable * Up to 4 wxCode fields may be present in response * Up to 4 RVR sets of fields may be present in response * Only fields with values are included in responses ## [1.3.0] 2025-02-03 ### Add new parameter handling to select by insert time... * inserted after datetime * inserted through datetime ### Documentation updates ## [1.1.0] 2024-11-06 ### Add METAR API with new endpoints * spatial filters * temporal filters * data filters, including by stationId and flightCategory --- # METAR API information _last updated for v1.7.3_ For a given station only the one object associated with the latest raw METAR report will be returned in responses. METARs are considered valid beginning with their reported time. Records are given an expiration time of 2 hours following that report time to limit their availability. As a rule, a new report for a station should comes one hour or less after a previous report and become the new active report. See documentation for complete request parameter definitions. Response data is in GeoJSON format. See Postman collection for description of properties in response feature objects. Many data fields frequently have no content for any given report and are removed from response objects when that is the case. See Postman collection for details. Values with units are provided in either \"default\" (mostly, but not all, imperial) or \"metric\" system. See documentation or Postman collection for details. ## Spatial filters These allows to select data within a specific area. Only one may be used per request. * Bounding box - Defines rectangular area set by furthest southwest location and furthest northeast location. * Polygon - Defines area enclosed by series of points. Response behavior is unpredictable if created shape is self-interesting other than last point matching first point. * Circle - Defines area from center point and radius. The larger the defined area, the more its shape on projected map will differ from true circle on spherical coordinates. Constraint is set to limit radius and thus circle size. Request will fail or have unpredictable response behavior if circle area crosses the antimeridian (180W/180E longitude). * Corridor - Defines area from series of points defining a (not necessarily straight) line and halfwidth that tells distance from line to encompass. Constraint is set to limit halfwidth, though line length not limited. However response behavior is unpredictable for long distances between points. Request will fail or have unpredictable response behavior if corridor area crosses the antimeridian (180W/180E longitude). ## Temporal filters These allow to select based on time-related characteristics on data. Parameters can limit responses to data valid at a particular time or within a timeframe, ingested/saved within a timeframe, and for data from forecast models corresponding to specific model run times. * valid at - Allows to specify an exact time to limit to data valid then. * from/until - Allows to set a timeframe to limit to data whose valid periods overlap at all with that timeframe. * inserted after/through - Allows to set a timeframe to limit to data ingested/saved at some time within that period. This is useful for chaining requests to continually acquire newly available data, like by setting the \"after\" time as the latest insert time seen from a previous request and the \"through\" time as the current time. ## Data fields About certain properties that may be seen in response objects... ### weather codes * may be up to four, but only provided as have available data * labeled `wx1`, `wx2`, `wx3`, `wx4` * combinations are split into separate wx code values, e.g., \"VCTS\" will have two codes \"VC\" and \"TS\" ### WMO codes * may be up to four, but only provided as have available data * labeled `wmoCode1`, `wmoCode2`, `wmoCode3`, `wmoCode4` * involve re-creating tokens that may have been split in making `wx#` values * e.g., case with `wx1=VC`, `wx2=TS`, and `wx3=RA` from `rawTxt` containing `...VCTS RA...` will have `wmoCode1=VCTS` and `wmoCode2=RA` ### Runway visual range (RVR) * each RVR may report subset of Runway, Visibility, VisibilityBeyondBound, VisibilityTendency, MaxVisibility, MaxVisibilityBeyondBound, MaxVisibilityTendency, only providing values * may be up to four, but only provided as have available data * field names will include integer indicating which report, like \"rvr1Runway\" and \"rvr1Visibility\" "