NOAA Aviation Weather Center API: Intelligence Source Guide

The Aviation Weather Center serves observations, forecasts, pilot reports, hazard advisories and upper-air winds through a keyless government API. It is the authoritative free source for aviation meteorology and the only one in this catalogue carrying winds aloft.

At a glance

Source	NOAA Aviation Weather Center API
Category	Aviation & Space › NOTAMs & Aviation Weather
Homepage	https://aviationweather.gov/
Machine interface	`https://aviationweather.gov/api/data`
Format	`JSON`
Access	Open — no account required
Disciplines	Meteorological Intelligence
Mission domains	Aviation Security, Maritime Security

METAR, TAF, PIREP, SIGMET/AIRMET, winds aloft and G-AIRMET for flight weather; JSON/XML/CSV, no key. — as catalogued in the platform’s own source registry.

The Aviation Weather Center is a US National Weather Service unit that assembles and distributes aviation meteorological products, and its public API exposes those products as machine-readable data without a key or an account. The product families are distinct and worth separating in your head. Observations – METAR and SPECI – are point reports from aerodromes worldwide, received through international exchange. Forecasts – TAF – are aerodrome forecasts from the responsible national services. Pilot reports are human observations made from aircraft in flight, covering turbulence, icing, cloud tops and conditions between stations. Hazard products cover significant meteorological phenomena: international SIGMETs issued for flight information regions, and the US-specific AIRMET and graphical AIRMET products describing widespread moderate hazards. Winds and temperatures aloft give the vertical wind field at standard levels. Station and airport reference data supports all of it. Output is available in several formats – JSON, XML, CSV and raw text among them – and the service replaced an older text data server whose endpoints have been retired, so any integration written against legacy paths needs rebuilding.

Three things make this the reference source rather than a convenience. First, it is the authority: this is a government meteorological service, its products are the official ones, and for US operations it is an approved briefing source, which is a standard no third-party parser can meet. Second, it carries the hazard and upper-air products that convenience APIs do not – SIGMETs, AIRMETs, pilot reports and winds aloft – and those are the products that explain the interesting behaviour. A route deviation is explained by a SIGMET, not by a METAR at the departure field. Third, and least obviously, the winds aloft product is a general-purpose analytical tool that has nothing to do with aviation: any question involving something drifting through the atmosphere – a high-altitude balloon, an uncrewed aircraft's ground track versus its heading, a smoke or chemical plume, debris from an event, contrail persistence – is a wind field question, and this is a free, global, keyless way to get one. That makes the source relevant to METOCINT work well outside its nominal aviation domain.

Who publishes it, and why that matters

This is a US federal government service, funded by appropriation and operated as part of the national weather infrastructure. The implications are unusually favourable and worth stating plainly: there is no commercial incentive shaping the data, the products are official rather than derived, output of the US government is generally not subject to copyright, and no account or key is required so there is no relationship in which your interest is recorded. The implications that cut the other way are structural rather than commercial. Availability is subject to government funding and operational decisions, and services have been interrupted during funding lapses. The service is periodically redesigned, and the last such change retired a widely used legacy interface, breaking integrations across the community; assume this will happen again on a timescale of years. And the international products it redistributes are only as good as the originating national services, over which it has no control. Longevity is excellent; interface stability is not.

Provenance is the first question to ask of any dataset and the one most often skipped. Who collects it, what their incentive is, whether they publish a methodology, and whether they correct the record when they get something wrong all bear directly on how much weight a finding drawn from it can carry.

What a record actually contains

The fields you will be working with, what each one means, and whether it is something you can pivot on. Read the meanings carefully — more analysis is wrecked by misreading a field than by failing to find one, and a field that looks like an observation is often an inference.

Field	Type	What it means	Pivot value
`icaoId`	string	The four-letter location indicator of the reporting station. The join key to airport reference data and the identifier to use in preference to any name string.	Airport entity, station metadata, flight track correlation, aerodrome-level analysis.
`obsTime`	timestamp	The time the observation refers to. Distinct from the time the report was received or served, and it is the time that matters for correlation.	Timeline alignment with tracks, incident reconstruction, imagery pass timing.
`receiptTime`	timestamp	When the product was received by the distribution system. The gap between this and observation time is the transmission latency, which varies enormously by country.	Latency assessment; identifying national services whose data arrives too late for operational use.
`rawOb`	string	The report text as issued. The artefact of record – every structured field in the response is derived from this, and it is what you keep for evidential purposes.	Independent re-parsing, verification against the issuing service, certified record request.
`lat / lon / elev`	float	Station position and elevation. Present in observation responses so that a report can be placed geographically without a separate lookup.	Spatial correlation with tracks and events; determining whether a station is representative of a location of interest.
`wdir / wspd / wgst`	int	Wind direction in degrees true, sustained speed and gust. Variable and calm conditions are encoded specially and do not reduce to a single direction.	Runway configuration inference, plume and drift analysis, aircraft performance.
`visib`	string	Prevailing visibility, expressed in the units of the reporting convention and carrying qualifiers such as greater-than markers rather than being a plain number.	Observation feasibility, imagery plausibility, operational minima and diversion analysis.
`clouds`	array	Cloud layers with coverage and base height above the field. Ceiling is the lowest broken or overcast layer and is a derived concept rather than a reported one.	Ceiling derivation, optical imagery plausibility, approach and departure feasibility.
`wxString`	string	Present weather group encoding phenomena such as precipitation type, obscuration and intensity in the standard abbreviations. Automated stations report a restricted subset of these.	Phenomenon-level analysis; be aware of what an automated station cannot report.
`fcsts`	array	In TAF responses, the ordered forecast periods with validity times and change indicators. Each element is a conditional expectation, not a scheduled event.	Explaining pre-emptive operational decisions visible in tracking data.
`hazard`	enum	In SIGMET and AIRMET products, the phenomenon type – turbulence, icing, convection, volcanic ash, dust and others. This is the field that explains large-scale route deviations.	Airspace avoidance analysis, route deviation explanation, volcanic and dust event tracking.
`coords`	array	The polygon or area to which a hazard product applies. Hazard products are areal, unlike observations, which is what makes them useful for explaining behaviour between stations.	Geospatial intersection with flight tracks, airspace and FIR analysis.
`validTimeFrom / validTimeTo`	timestamp	Validity window of a hazard product or forecast. Products outside their window are historical records and must not be presented as current conditions.	Temporal intersection with events; distinguishing active advisories from expired ones.
`turbulence / icing`	array	In pilot reports, the reported intensity and altitude band of turbulence or icing. These are subjective human assessments by a crew member, not instrument measurements.	Between-station conditions, corroboration of hazard products, explanation of altitude changes in tracks.
`wind and temperature aloft`	array	Forecast wind direction, speed and temperature at standard flight levels for a grid of points. The vertical wind field, which no other source in this batch provides.	Trajectory and drift analysis for balloons, uncrewed aircraft, plumes and debris; ground speed reconciliation in track analysis.

Coverage — and what is not in it

Coverage differs sharply by product and this is the single most important thing to understand about the source. Observations and forecasts are global, because METAR and TAF are exchanged internationally and the centre redistributes what it receives; quality, latency and completeness for any given country are properties of that country's meteorological service, not of this one. Hazard products are mixed: international SIGMETs are issued by meteorological watch offices for flight information regions worldwide and are redistributed here, while AIRMET and graphical AIRMET products are US constructs covering US airspace and have no equivalent in most of the world. Pilot reports are overwhelmingly North American, because the reporting culture and the collection infrastructure are strongest there; a search for pilot reports over most of the world returns nothing and that absence means nothing about conditions. Winds and temperatures aloft are model output with genuinely global scope in the underlying models, though the packaging here is oriented to North American flight planning. Update rhythm follows the products: observations roughly hourly with specials in between, TAFs several times daily, hazard products on issue and amendment, winds aloft on the model cycle. There is no deep archive here; this is a current-conditions service.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which NOAA Aviation Weather Center API will not show you something that is nevertheless real:

Hazard product coverage is not global in the way observations are, so an absence of AIRMET-type advisories outside US airspace reflects a difference in national practice rather than an absence of hazardous weather.
Pilot reports are concentrated in North America to the point where the product is effectively regional, and treating a lack of reports elsewhere as evidence of smooth conditions is a straightforward error.
Redistributed international data inherits the originating service's problems – late transmission, station outages, non-standard formatting – and the response gives no indication of which national service is performing poorly.
Aerodromes that do not participate in international exchange, including many military and restricted fields, are simply absent, so areas of high intelligence interest can be meteorological blanks.
The service is oriented to current and near-term conditions; there is no substantial historical archive, so reconstructing conditions at a past date requires a different NOAA product entirely.
Winds aloft are model forecasts rather than measurements, so they carry model error that grows with forecast lead time and is largest exactly in the data-sparse regions where you most want them.
Availability is subject to US government funding and operational decisions, and the service has been interrupted during funding lapses, which is a dependency worth documenting for any operational workflow.
The interface has been redesigned with legacy endpoints retired, so documentation, code samples and tutorials found online are frequently for an interface that no longer exists.
Products are aviation-shaped: they describe conditions relevant to flight at aerodromes and along routes, and they do not describe surface conditions away from airports, which is a poor fit for questions about ground-level weather at an arbitrary point.

Write the blind spot into the product. A statement that something “was not observed in NOAA Aviation Weather Center API” is defensible; a statement that it “did not happen” is not, and the difference is what survives cross-examination.

Access, licensing and what you may do with it

Access model: Open — no account required

There is no key and no account. Requests are HTTP GETs against product-specific paths under the data API, with parameters selecting the stations, bounding box, time window and output format, and the same product is generally available in raw text, JSON, XML and CSV. Field names differ between products – an observation response and a hazard response share very little schema – so build against a live response for each product family you use rather than assuming a common shape. The site's own API documentation is the authoritative reference and should be checked before writing anything, particularly because the legacy text data server that many older examples target has been retired. For bulk or continuous work, prefer bounding-box queries over per-station loops, request only the fields and formats you need, and cache in line with each product's update rhythm. If your requirement is genuinely large-scale or historical, the appropriate route is the archival and model-output services elsewhere in NOAA rather than heavy polling of an operational endpoint.

Licence

Works of the US federal government are generally not subject to domestic copyright, and these products are made available for public use without registration or fee. That is the most permissive licensing position of any source in this batch and it is a genuine advantage for anyone building a product or publishing analysis. Two qualifications matter. First, the international observations and SIGMETs redistributed here originate with foreign national meteorological services, some of which do assert rights over their data, so a bulk redistribution product should consider the position of the originating services rather than assuming the US position covers everything. Second, permissive licensing is not endorsement: presenting derived analysis in a way that implies official meteorological status or government approval is a misrepresentation regardless of the licence. Attribution to the National Weather Service and the Aviation Weather Center is good practice and costs nothing.

Rate limits and fair use

No published quota, which places the burden on you to behave like a good citizen of shared public infrastructure. Match your polling to the products' actual update rhythm: nothing is gained by requesting an hourly observation every minute, and hazard products change on issue rather than continuously. Use bounding boxes and multi-station requests rather than looping over stations individually, which reduces both your request count and the server's work by a large factor. Cache aggressively and serve repeat internal requests from the cache. Set a descriptive user agent identifying your organisation with a contact address, which is standard practice for government data services and is what allows an operator to contact you rather than block you. If you find yourself needing sustained heavy access, that is a signal to move to bulk and model-output distribution channels designed for it.

Licensing changes, and it changes without warning. A dataset that was free for research this year may not be free for commercial or evidential use next year. Confirm the current terms before you build a dependency on it, and record the terms you relied on alongside the data — the licence in force at the time of collection is part of the provenance.

Collecting it

How NOAA Aviation Weather Center API is actually pulled, in the order you would set it up. Prefer the bulk or export interface over per-item lookups wherever one exists: it is kinder to the publisher, faster for you, and gives a reproducible snapshot rather than a series of point-in-time answers you cannot reconstruct later.

Method	Format	Cadence	Notes
Observations by bounding box	JSON	poll every 15 to 20 minutes; cache accordingly	The efficient way to collect current conditions across an area of interest. Far better than per-station polling for both you and the service.
Forecasts by station set	JSON	poll a few times daily	TAFs for the aerodromes in your case. Always store issue time and validity window so a forecast cannot later be mistaken for an observation.
Hazard advisories	JSON	poll every 15 to 30 minutes	SIGMET and AIRMET products with their polygons. These explain route deviations and altitude changes that observations cannot.
Pilot reports	JSON	poll every 15 minutes during periods of interest	Human in-flight observations, effectively North American in coverage. The only source of conditions between stations and at altitude from a human observer.
Winds and temperatures aloft	JSON	refresh on the model cycle	The vertical wind field. Collect this whenever your work involves anything drifting – balloons, uncrewed aircraft, plumes, debris – not only when it involves aircraft.
Station and airport reference	CSV	once; refresh quarterly	Stable reference data. Mirror locally and join against your airport entities rather than querying repeatedly.

Ingesting it into the platform

Every step below is idempotent and cursor-based: interrupt one and it resumes from where it stopped rather than duplicating rows or losing progress. Collection is recorded per source, so a feed that quietly stops publishing shows up as a stale timestamp instead of silently thinning your coverage.

Register products separately — Add each product family in sources.php as a distinct collection rather than registering the site once, because observations, hazards, pilot reports and winds aloft have different coverage, cadence and reliability and should not share a single quality assumption.
Schedule per-product collection — Drive each family from collect.php on its own cadence under cron.php, matched to how often that product actually changes, so that quota discipline and freshness expectations are encoded in the schedule rather than in an analyst's head.
Preserve raw text with every record — Store the issued report or advisory text alongside the parsed structure in ingest.php. The raw text is the artefact of record and the only basis for re-deriving or challenging a parsed value later.
Normalise time and units — Convert everything to UTC and to a single internal unit system on ingest, keyed off the product's own conventions, and store observation time and receipt time as separate fields so that latency remains visible.
Geometrise hazard products — Convert advisory polygons into spatial objects on ingest so that correlate.php can intersect them with flight tracks directly, which is what turns a hazard advisory into an explanation of an observed deviation.
Correlate with the movement picture — Join conditions, advisories and winds aloft against ADS-B tracks and datalink traffic on time and geography, so that holds, diversions, altitude changes and route deviations resolve automatically where weather explains them.
Place on the case timeline — Push the relevant observations and advisories into timeline.php next to the movement and reporting record, with validity windows rendered as intervals rather than points so expired advisories are visibly expired.
Alert on conditions, not just events — Configure rules on hazard issuance over watched geography and on threshold conditions at watched aerodromes, so that the environmental cause is flagged before the operational effect appears in the movement data.

Registered sources and their last-collected state are listed in sources.php, and the scheduled chain that keeps them current is in automation.php.

How it is wrong, and how to tell

Every dataset is wrong in characteristic ways. Knowing which ways is the difference between using a source and being used by one, and it is the part of source evaluation most often skipped because it is the part that takes work.

This is the highest-quality source in the batch and the basis for saying so is institutional. The products are official output of national meteorological services made under international standards, aerodrome observations are made by trained observers or certified automated systems, forecasts are issued under regulatory obligation, and hazard advisories are issued by designated watch offices. There is no commercial layer between the observer and you. The quality variation that does exist is national rather than systemic: the timeliness and completeness of what arrives from any given country is a property of that country's service, and it ranges from excellent to intermittent. Pilot reports are a different kind of data and should be judged differently – they are subjective human assessments with positions often estimated rather than measured, valuable precisely because they observe things instruments do not, and unreliable in exactly the ways human reports are. Winds aloft are model output and carry forecast error that grows with lead time. Judge any specific value by its product family, its originating service and, for forecasts, its lead time, and record the raw text so the judgement can be revisited.

Characteristic false positives

Expired hazard advisories read exactly like current ones unless you check the validity window, and an advisory quoted outside its window is a confident statement about conditions that were no longer forecast.
The absence of a pilot report is meaningless outside North America but looks identical to an absence in a well-reported area, so any analysis that treats pilot report density as a proxy for conditions is measuring reporting culture.
Redistribution latency varies by country, so a station appearing to have stopped reporting may simply be transmitting slowly, and treating the gap as a station outage produces a wrong conclusion about the aerodrome.
Winds aloft are forecasts, and using a long-lead forecast for trajectory work in a data-sparse region produces a drift track with error bounds far larger than the confident-looking numbers suggest.
Ceiling is derived from broken and overcast layers only, and computing it from the lowest layer of any coverage yields a systematically wrong operational category.
Pilot report positions are frequently estimated relative to a navigation aid or a route point rather than measured, so plotting them as precise coordinates overstates their spatial accuracy by tens of kilometres.
Automated observing systems report a restricted set of phenomena, so the absence of thunderstorm, precipitation type or obscuration in an automated report is not evidence that none occurred – a distinction that matters most when weather is used to refute a claim.
US-specific product types are easy to mistake for global ones, and building an analysis around AIRMET-style coverage outside US airspace produces a picture with systematic holes that are invisible from inside the data.

None of these make the source unusable. They make it a source that requires corroboration before an assertion built on it goes into a product, which is true of every source and admitted by few.

Ageing

Each product family ages on its own clock and mixing them is where errors come from. Observations are superseded roughly hourly, with special reports in between when conditions change materially, so an observation more than about an hour old should be treated as historical rather than current. Forecasts are superseded by scheduled reissue and by amendment, and an unamended forecast late in its validity is materially weaker evidence than a fresh one. Hazard advisories have explicit validity windows and are simply invalid outside them; there is no interpretation to make. Pilot reports describe a moment at a point and age within tens of minutes for turbulence and icing purposes. Winds aloft degrade with forecast lead time rather than with wall-clock age, so a six-hour forecast is better than a twenty-four-hour one issued at the same time. The characteristic stale record is an observation from a station whose transmission has stopped: it retains its original observation time and is simply never replaced, so compare observation time against wall clock on every use and treat anything beyond your threshold as unknown rather than as current.

What this source feeds

A source is only worth what it lets you conclude. These are the disciplines that collect through it, the mission domains it serves and the data points it yields — every one is a tag, so you can follow any thread from here into the rest of the library.

Collected by these intelligence disciplines

Meteorological Intelligence

Serves these mission domains

Yields these data points

How each sector uses NOAA Aviation Weather Center API

The same dataset is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The records are shared — the constraints, thresholds and outputs are not.

🎖 Military and defence

This is an approved and authoritative meteorological source in its own domain, and its analytical uses extend well beyond flight weather. Hazard advisories and winds aloft support trajectory work on anything airborne and uncontrolled, from high-altitude balloons to uncrewed systems to debris and dispersal problems, which makes it a METOCINT tool rather than only an aviation one. For observed activity, conditions at a base explain sortie rates and ground stops, and hazard polygons explain route deviations that would otherwise be read as intent. The coverage gap at military and restricted aerodromes worldwide is the standing limitation, and the nearest reporting civil field may be meteorologically unrepresentative of it.

🕵 National intelligence

The default weather source for explaining anomalies in air movement and for constraining what other collection could have seen. Hazard advisories are the product that closes the largest number of open questions, because a route deviation across a SIGMET polygon is explained and needs no further analysis. Winds aloft support drift and trajectory reconstruction for objects that do not fly under their own control, which is a recurring question in aerial incursion and overflight analysis. The absence of a key means no account trail linking your organisation to the geography you are interested in, which is a genuine and unusual advantage among the sources in this catalogue.

👮 Law enforcement

Supports incident reconstruction – what conditions were at a location and time, whether visibility supported a claimed observation, whether weather explains an aircraft or vessel's behaviour. Because these are official government products, the evidential position is stronger than for any derived API, though for court purposes the right artefact is still a certified record obtained from the meteorological service rather than an API response captured by an analyst. Note that the service is current-conditions oriented; historical reconstruction requires the archival NOAA products, and requesting those early in an investigation avoids a scramble later.

🔍 Private investigation and corporate security

The authoritative free source for accident, insurance and liability work where environmental conditions are in dispute, and the practical source for judging whether surveillance conditions supported an observation. Its advantages over consumer weather services are that it carries the actual aviation observation rather than a modelled area forecast, and that it is free of licensing entanglements. Keep the raw report text in the file, record which station answered and how far it was from the location in question, and obtain a certified record from the meteorological service for anything that will be relied on formally.

📰 Journalism and OSINT media

Free, authoritative, citable and unrestricted by licence, which makes it the right source for any reporting that turns on weather – delay and diversion explanations, whether conditions supported a described event, whether a claimed sighting was physically possible. Cite the National Weather Service and the specific product, give the station and the observation time, and be explicit about the observation-versus-forecast distinction that most coverage gets wrong. Hazard advisories with their polygons are particularly good for visual reporting because they are areal rather than point data and map directly.

🌍 NGO, humanitarian and human rights

Humanitarian air operations, disaster response and access planning need aerodrome conditions and hazard advisories for the specific fields being used, and this is the authoritative free way to get them. Winds aloft additionally support dispersal and drift questions in chemical, industrial and fire incidents, which is a use well outside aviation but squarely within humanitarian assessment. The limitation is the familiar one: austere, damaged and unlicensed fields do not report, so the nearest station may be distant, and the assessment should record that distance rather than implying the report describes the site.

🎓 University and research

A standard reference for aviation meteorology teaching and for research where official current products are required, with the important caveat that research usually needs archives rather than current conditions and should therefore go to the NOAA archival and model-output services. For reproducibility, capture and store the exact products you used with their raw text and retrieval times, because an operational endpoint returns current data by design and cannot be re-queried for a past state. The permissive licensing position makes this unusually straightforward to use and redistribute in published research compared with commercial meteorological data.

Playbook: working NOAA Aviation Weather Center API end to end

A repeatable sequence from first pull to finished product. Each phase states what you are trying to establish, not merely what to click — the objective is a defensible chain of reasoning, not a completed checklist.

Phase 1 — Choose the product before you choose the query

Decide which family answers your question: observations for what conditions were at a field, forecasts for what was expected, hazard advisories for why an aircraft avoided an area, pilot reports for conditions between stations, winds aloft for anything drifting. Analysts who reach reflexively for METAR answer route-scale questions with point data and get them wrong.

Phase 2 — Establish the coverage of your chosen product

Observations are global, hazard advisories are mixed, pilot reports are effectively North American, winds aloft are model-wide. Write down which regime you are in before drawing any conclusion from an absence, because absence means something completely different in each.

Phase 3 — Fix the UTC window first

Determine the exact time interval you care about and retrieve the products that bracket it, rather than retrieving current data and reasoning backwards. Aviation weather is a sequence of discrete issuances, and the product you need is usually the one immediately preceding your event.

Phase 4 — Keep the raw text with every record

Store the issued text alongside anything parsed. It is the artefact of record, it is what a certified request will be matched against, and it is the only way to re-derive a value when your interpretation is later challenged.

Phase 5 — Turn hazard advisories into geometry

Convert advisory polygons into spatial objects and intersect them with flight tracks. This single step converts a large class of apparent anomalies into explained behaviour automatically, and it is the highest-value integration in this entire source.

Phase 6 — Use winds aloft beyond aviation

Whenever the question involves an object moving with the air rather than through it – a balloon, an uncrewed system in a strong wind, a plume, debris – retrieve the vertical wind field and reconstruct the drift. Most analysts never think to use an aviation weather source this way, and it is often the fastest route to an answer.

Phase 7 — Treat pilot reports as human reporting

Handle them with the tradecraft you would apply to any human observation: subjective intensity assessments, positions often estimated, reporting biased towards areas with dense traffic and a strong reporting culture. Their value is that they observe what instruments cannot, and their weakness is everything else.

Phase 8 — Check validity windows on everything conditional

Hazard advisories and forecast periods have explicit start and end times. An expired advisory quoted as current is one of the easiest and most damaging errors to make with this source, because the text is indistinguishable from a live one.

Phase 9 — Test whether other sources could have seen what they claim

Use ceiling, visibility and phenomena to constrain optical imagery and ground observation. If conditions at the time preclude a claimed sighting, that is a finding about the claim. This is a cheap and underused analytical move.

Phase 10 — Separate national data quality explicitly

When working across countries, track the latency and completeness of each originating service. Some report promptly and completely; others do not. Attributing a gap to conditions rather than to a national service's transmission practice is a systematic error in international work.

Phase 11 — Go to the archive for anything retrospective

This is an operational current-conditions service. If your question is about a date in the past, use the NOAA archival products, which hold long records with documented quality control. Trying to reconstruct history from an operational endpoint produces an incomplete record and wastes the endpoint's capacity.

Phase 12 — Document the dependency

Record in the case or the system design that this source depends on US government funding and that the interface has been redesigned before with legacy endpoints retired. Both are real operational risks and both are easier to manage as documented assumptions than as surprises.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

What to pair it with

No single source carries a finding. These are the datasets that corroborate, extend or contradict this one — and a source that contradicts is worth more than one that agrees, because it is the only thing that will tell you when you are wrong.

Source	Relationship	What it adds
AVWX REST API	extends	Parses the same observation and forecast code forms into structured JSON with derived flight rules and coordinate-based nearest-station lookup, which this service does not offer in the same form.
NOAA archival environmental data	supersedes	The correct route for historical reconstruction, with long quality-controlled records that an operational current-conditions endpoint cannot provide.
Iowa Environmental Mesonet	extends	Practical archived access to long runs of aviation observations, widely used where the official archive route is slower than an investigation allows.
NOAA model output distribution	extends	Gridded numerical model data for trajectory, dispersion and upper-air work at higher resolution than the packaged winds aloft product.
OpenSky Network	corroborates	The movement data that hazard advisories and conditions explain. Intersecting tracks with advisory polygons is where this source delivers most of its analytical value.
Airframes.io	corroborates	Datalink traffic includes weather requests and diversion messages whose meaning only becomes clear against the actual conditions and advisories in force.
OurAirports	prerequisite	Airport reference data for identifying which fields exist near a location of interest, including those that do not report weather at all.
National meteorological services	supersedes	The issuing authorities for international observations and SIGMETs redistributed here, and the source of certified records for evidential use.

Legal, ethical and operational constraints

This is the least legally encumbered source in the batch. There is no personal data, no account, and no key; US federal government works are generally not subject to domestic copyright and the products are published for public use. Three points still deserve attention. Internationally redistributed observations and advisories originate with foreign national services whose own positions on data rights vary, so a bulk redistribution product should look upstream rather than assume the US position governs everything. Permissive licensing is not endorsement, and presenting derived analysis as an official meteorological product or as government-approved is a misrepresentation regardless of the licence. And where weather evidence will be relied on formally, the appropriate artefact is a certified record from the issuing meteorological service, not an analyst's capture of an API response – obtain it early. Attribution to the National Weather Service and the Aviation Weather Center is good practice and should appear in any published product built on this data.

Operational security

The absence of authentication means there is no account tying your organisation to the geography you query, which is a meaningful advantage over any keyed weather API. The residual exposure is ordinary network-level observability: the operator sees your source address, timing and the areas or stations you request, and weather queries are unusually revealing in aggregate because nobody looks up conditions at obscure aerodromes idly. A concentrated pattern of requests around one remote airfield is a legible statement of interest. Mitigate by using bounding boxes that are larger than your actual area of interest, by caching so that repeat internal interest never generates outbound traffic, and by routing through infrastructure not attributable to your organisation where the matter warrants it. Note also the reverse consideration: this is a US government service, and for some organisations the fact of querying US government infrastructure is itself a consideration in their own threat model.

Two rules that hold regardless of jurisdiction. Collection that is lawful is not automatically proportionate, and a dataset assembled for one purpose does not carry consent for another. Where the records concern identifiable people, the question is not only whether you may hold the data but whether holding it serves the purpose you are accountable for.

Is it earning its place?

Sources accumulate. Feeds get added during an incident and are never reviewed again, and a decade later the pipeline is carrying dead weight that nobody dares remove. These are the measures that show whether NOAA Aviation Weather Center API is contributing anything, and they are worth baselining now so the answer is available later.

Product-level freshness, measured as observation time minus retrieval time and tracked separately per family, since a single blended figure hides the product that has quietly stopped updating.
Redistribution latency by originating country, which tells you which national services can support time-sensitive work and which cannot, and is invisible unless you measure it.
Proportion of flight track anomalies automatically explained by intersecting hazard polygons, which is the direct measure of whether the geometric integration is earning its cost.
Coverage rate of reporting stations within a usable distance of your recurring areas of interest, which is an honest assessment of the source against your geography rather than against the world.
Request volume against unique product-hours retrieved, which distinguishes cadence-matched collection from wasteful polling of data that changes hourly.
Count of occasions on which winds aloft supported a non-aviation trajectory or dispersion question, since that is the source's least obvious and often highest-value contribution.
Number of claims from other sources constrained or refuted by conditions, which measures the plausibility-testing role that most analytical teams underuse.

Beware of volume. Indicator counts rise easily and say almost nothing. Unique contribution — findings this source produced that no other source in your stack would have — is the measure that matters, and it is usually far lower than anyone expects.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

Match the product to the scale of the question. Point observations answer questions about an aerodrome; hazard advisories answer questions about a route; winds aloft answer questions about a trajectory. Most weather-related analytical errors are scale errors rather than data errors.
Coverage regime differs per product, and this is the fact to internalise. Global observations, mixed hazard products, regionally concentrated pilot reports and model-wide winds aloft cannot share one assumption about what an absence means.
Validity windows are not advisory. A hazard product outside its window is invalid, full stop, and the text gives no visual clue. Build the check into the pipeline rather than trusting an analyst to look.
Use the winds aloft product for things that are not aircraft. Balloons, uncrewed systems, plumes and debris are all wind-field problems, and a free global keyless source of the vertical wind field is a more general analytical asset than its aviation framing suggests.
Pilot reports are human intelligence with a tail number. Apply source-evaluation habits: subjective intensity, estimated positions, reporting bias towards busy airspace. They see what instruments cannot, and that is the whole reason to use them.
Track national data quality separately when working internationally. Latency and completeness are properties of the originating service, and confusing a slow national feed with a quiet aerodrome is a recurring error.
Keep the raw text. Every structured field is derived from it, certified records are matched against it, and the parsed representation you store today may not be the one you want in six months.
Weather is a constraint on other sources, not just a subject in itself. Ceiling and visibility bound what imagery and observers could have seen, and applying that test is cheap, fast and rarely done.
Assume the interface will change again. It has been rebuilt with legacy endpoints retired, the community's code samples are frequently for the old one, and a written note in your system design about this dependency will save someone a confusing week.

Questions analysts actually ask

Is this data global or US-only?

It depends on the product, and getting this wrong is the most common mistake. Observations and forecasts are global through international exchange. International SIGMETs are worldwide. AIRMET-type products are US constructs. Pilot reports are effectively North American. Winds aloft are model-based with global underlying coverage but a North American packaging focus.

Do I need an API key?

No. There is no key and no account, which is both convenient and useful operationally, because it means there is no record linking your organisation to the locations you are interested in. The tradeoff is that there is no quota you can rely on either, so cadence discipline is your responsibility.

Can I use this for historical weather?

Not effectively. It is an operational current-conditions service. For a past date, use NOAA's archival environmental data services, which hold long quality-controlled records. Trying to build history from an operational endpoint gives you an incomplete record and consumes capacity intended for live use.

Why do my code samples not work any more?

Almost certainly because they target the retired legacy text data server. The interface was rebuilt and the old endpoints were withdrawn, but a great deal of tutorial material online still shows them. Work from the site's current API documentation and build against live responses.

How reliable are pilot reports?

They are subjective human observations, which makes them uniquely valuable and characteristically imprecise. Intensity assessments vary between crews and aircraft types, positions are often estimated relative to a route point rather than measured, and reporting is dense only where traffic and reporting culture are. Use them for conditions between stations, and weight them as human reporting.

Can I use winds aloft for something that is not an aircraft?

Yes, and it is one of the best uses of this source. Anything drifting with the atmosphere – a high-altitude balloon, debris, a smoke or chemical plume, an uncrewed system in strong wind – is a vertical wind field problem, and this gives you that field globally, free and without an account.

How does this compare with a parsing API like AVWX?

This is the authority and carries the hazard, pilot report and upper-air products the parsers do not. A parsing layer adds structured output, derived flight rules and coordinate-based station resolution. Serious pipelines use both: the government service for authority and product breadth, a parser for consistent structure.

What happens during a US government funding lapse?

Services have been interrupted before. Treat this as a documented dependency in any operational design, keep a local cache that degrades gracefully, and know which alternative sources you would fall back to. It is a low-probability, high-visibility failure that is far easier to handle as a planned assumption.

Is API output good enough for court?

It is good enough to direct an investigation and usually not the right artefact for proceedings. Obtain a certified observation record from the issuing meteorological service for anything relied on formally, and in the meantime retain the raw report text and your retrieval time so the certified record can be matched to what you analysed.

Standards, formats and interoperability

What this source speaks natively, and what it has to be translated into before a partner can consume it. Work that arrives in a recognised format is easier to defend, easier to hand over and easier to automate against:

METAR and SPECI are the international aerodrome observation code forms defined in the WMO manual on codes and mandated for aviation through ICAO Annex 3.
TAF is the international aerodrome forecast code form, with change groups whose conditional semantics are the most commonly misread part of aviation weather.
SIGMET is the international standard advisory for significant en-route phenomena, issued by meteorological watch offices for flight information regions, and is distinct from the US-specific AIRMET family.
ICAO Annex 3 defines meteorological service for international air navigation and is the reason products from different countries are comparable at all.
ICAO four-letter location indicators identify aerodromes and FIRs, and are the join key between weather products, airport data and flight information regions.
IWXXM is the XML and GML exchange representation increasingly used alongside traditional alphanumeric code forms for machine-readable distribution.
Flight information region boundaries determine which authority issues advisories for a given airspace, which is why hazard product availability varies by region rather than by weather.
The platform exports weather and hazard context attached to aircraft, airport and event entities in STIX 2.1, MISP, CSV, JSON and JSONL alongside the movement data it explains.

References

Primary documentation and authoritative references for this source. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

Aviation Weather Center — NOAA National Weather Service. The service itself and its current API documentation. The authoritative reference for endpoint paths, parameters and product definitions, and the place to check before writing any integration.
National Weather Service — NOAA. The parent service, with the wider product set and the documentation of how aviation products fit into the national weather infrastructure.
National Centers for Environmental Information — NOAA. The archival route for historical observations, which is what retrospective reconstruction requires and this operational service cannot provide.
NOMADS model data distribution — NOAA. Gridded numerical model output for trajectory and dispersion work at higher resolution than the packaged winds aloft product.
Federal Aviation Administration — FAA. Regulatory context for official weather briefing, airspace structure and the operational meaning of the hazard products served here.
International Civil Aviation Organization — ICAO. Annex 3, location indicators and flight information region structure, which together define what these products are and who issues them.
World Meteorological Organization — WMO. Custodian of the code forms and of the international exchange arrangements that make the global observation coverage possible.
Iowa Environmental Mesonet — Iowa State University. Widely used archive of aviation surface observations, and the practical fallback when the official archival route is slower than an investigation allows.
AVWX REST API — AVWX. The parsing layer over these same code forms, useful alongside this service when consistent structured output and coordinate-based station lookup are wanted.
OpenSky Network — OpenSky Network Association. The movement data that these products explain, and the other half of any weather-and-tracks correlation workflow.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this source: it collects each product family on its own cadence, converts hazard advisories into geometry that intersects flight tracks automatically, retains raw text for evidential follow-up, and makes the vertical wind field available for trajectory work far outside aviation.. Browse the full source catalogue, or follow any tag above into the rest of the library.