AVWX REST API: Intelligence Source Guide

AVWX is a parsing and normalisation layer over official aviation weather: it turns raw METAR and TAF code into structured JSON with derived flight rules, station metadata and coordinate-based nearest-station lookup. Useful precisely because it is not the authority.

At a glance

Source	AVWX REST API
Category	Aviation & Space › NOTAMs & Aviation Weather
Homepage	https://avwx.rest
Machine interface	`https://avwx.rest/api`
Format	`JSON`
Access	Free registration — API key at no cost
Disciplines	Aviation Intelligence
Mission domains	Aviation Security

Aviation weather REST API (parsed METAR/TAF, station and NOTAM data) with a free rate-limited token. — as catalogued in the platform’s own source registry.

AVWX is a REST service built on an open-source Python parsing engine. It takes the coded observations and forecasts that aviation runs on – METAR observations, TAF forecasts, and depending on the endpoint pilot reports, forecast model output and station reference data – and returns them as structured JSON with every element broken out: wind direction, speed and gust; visibility; cloud layers with type and base; temperature and dewpoint; altimeter setting; remarks; and a derived flight rules category. It also returns the sanitised and raw report text alongside the parsed structure, optional plain-language translations and a natural-language summary. A station endpoint returns airport reference data, and lookups accept not only ICAO and IATA identifiers but coordinates, resolving to the nearest reporting station. Access requires a free API token; paid tiers raise the limits. The engine underneath is published as open source, which means you can read exactly how any field was derived and, if you prefer, run the parser yourself against data you fetch directly.

The analytical job here is normalisation, not observation. AVWX does not measure anything; national meteorological services and airport observers do, and the data flows into international exchange from there. What AVWX supplies is the thing that is genuinely tedious to build and easy to get subtly wrong: a consistent parser for a code form that has decades of regional variation, non-standard remarks, human-entered errors and legitimate but rarely-seen groups. For an intelligence or investigative pipeline that needs weather as context – explaining why an aircraft held, why a flight diverted, whether conditions supported a claimed observation, what visibility was at a location at a time – the value is being able to ask the question by coordinate rather than by station identifier, and to get a comparable structured answer every time. The derived flight rules category in particular collapses a lot of aviation domain knowledge into one field. Treat it as an interpretation layer over an authoritative upstream, and keep the raw report so you can always go back to what was actually issued.

Who publishes it, and why that matters

AVWX is an independent project rather than an institutional service: it originates with a single developer, the parsing engine is open source and community-visible, and the hosted API is offered on a freemium basis with a free token and paid tiers above it. That combination is healthier than a purely free hobby service, because there is a revenue model that can sustain the hosting, but it is still a small operation without institutional backing. The consequences are practical. Free-tier limits exist to convert heavy users into paying ones, so an analytical pipeline that grows will eventually need a paid plan or its own deployment. Feature availability across endpoints has changed as the project has evolved, so verify what is currently offered rather than assuming a capability you read about once still exists. The strongest mitigation is the open-source engine: because you can run the parser locally against government feeds, you are not structurally dependent on this service surviving, which is a materially different risk position from a closed API.

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
`station`	string	The reporting station identifier the report belongs to. When you query by coordinate, this tells you which station actually answered, which may be some distance from your point of interest.	Airport entity, station metadata, distance from your area of interest – always check this before using the result.
`time`	timestamp	The observation or issue time of the report, in UTC. This is the time the report refers to, and it can be materially older than the time you retrieved it.	Correlation with flight tracks, incident timelines, imagery timestamps.
`raw`	string	The unmodified report text as issued. This is the authoritative artefact; everything else in the response is derived from it and should be checked against it when precision matters.	Independent re-parsing, verification against the issuing service, evidential record.
`sanitized`	string	The report after the parser has corrected spacing, ordering and common malformations. The difference between this and raw tells you how much repair the parser had to do, which is a quality signal.	Parser confidence assessment; a large delta warrants checking the original.
`flight_rules`	enum	Derived category – visual, marginal visual, instrument or low instrument conditions – computed from visibility and ceiling. It is an interpretation, not something the observer reported.	Operational feasibility assessment, diversion and hold explanation, alternate minima reasoning.
`wind_direction / wind_speed / wind_gust`	int	Wind as reported, in degrees true and the report's speed unit. Variable winds and calm conditions are encoded specially and do not reduce to a single number.	Runway in use inference, aircraft performance, drift analysis, smoke and plume dispersion.
`visibility`	string	Prevailing visibility, with the unit depending on the reporting convention – statute miles in some regions, metres in others. Values also carry qualifiers such as greater-than markers.	Observation feasibility assessment, ground-based imagery plausibility, operational minima.
`clouds`	array	Cloud layers with coverage, base height above the field, and type where reported. The ceiling is the lowest broken or overcast layer, which is a derived concept rather than a reported field.	Ceiling determination, satellite and aerial imagery plausibility, approach category.
`temperature / dewpoint`	int	Temperature and dewpoint in degrees Celsius. Their spread is the practical indicator of fog risk and is often more informative than either value alone.	Fog and icing assessment, aircraft performance, contrail formation likelihood.
`altimeter`	string	Pressure setting in inches of mercury or hectopascals depending on region. Directly relevant when reconciling barometric altitude in an ADS-B track against actual height.	Altitude correction for tracking data, pressure pattern analysis.
`remarks`	string	The remarks section, partly parsed into structured elements and partly returned as text. Remarks conventions are strongly regional and much of the content is not internationally standardised.	Manual reading for significant weather, sensor status and observer notes not present in the main body.
`forecast`	array	In TAF responses, the sequence of forecast periods with their validity times and change indicators. Each period is a prediction, and change groups are conditional rather than scheduled.	Planning context, explaining pre-emptive diversions and fuel decisions in track analysis.
`units`	array	The unit system applied to the parsed values, which varies by station and region. Ignoring this field is the fastest way to be wrong by a factor of several in visibility or wind.	Unit normalisation before any cross-station comparison.
`translations / summary`	array	Plain-language renderings of the parsed report, produced by deterministic templating from the parsed fields. Convenient for human review and never a substitute for the raw text.	Analyst readability; not a data field for downstream logic.

Coverage — and what is not in it

Coverage is inherited from the international meteorological exchange, so it is genuinely global for METAR and TAF at aerodromes that participate, and absent everywhere else. Major international airports worldwide report reliably, typically hourly or half-hourly for observations with amended reports when conditions change materially, and TAFs issued several times daily with validity periods of a day or more depending on the aerodrome. Regional and secondary fields report less consistently, some only during operating hours, which produces the common situation of a station that has data all day in one country and only from morning to evening in another. Military and restricted aerodromes frequently do not publish internationally, so an area of intelligence interest can have no reporting station at all despite having a substantial airfield. Coverage is by aerodrome, not by area: a report describes conditions at a point, and the nearest station to a location of interest may be tens of kilometres away across different terrain. There is no meaningful historical archive here – the service is oriented to current and forecast conditions, and retrospective work belongs to the government archives rather than to this API.

Known blind spots

Absence of evidence here is not evidence of absence. These are the conditions under which AVWX REST API will not show you something that is nevertheless real:

Nothing is observed here. Every value originates upstream, so an upstream outage, a station failure or a delayed transmission appears as missing or stale data with no indication of which of those occurred.
A report describes a point, not an area. Conditions at an aerodrome can differ completely from conditions at a location a short distance away, particularly in coastal, mountainous and urban terrain, and coordinate-based lookup makes this failure easier to commit because it always returns something.
Many aerodromes of intelligence interest do not report internationally at all, so the absence of weather data for a location says nothing about the airfield and everything about the reporting network.
Stations that report only during operating hours produce systematic gaps at night and at weekends, which correlates uncomfortably with the times an investigation is often interested in.
Remarks are only partly standardised internationally, so significant information encoded in regional remarks conventions is returned as text and will be missed by any purely structured analysis.
TAFs are forecasts, and treating a forecast period as a record of conditions is a category error that produces confident statements about weather that never occurred.
There is no radar, satellite, lightning or gridded model field here, so phenomena between reporting stations and the vertical structure of the atmosphere are entirely outside its scope.
The parser can only be as good as the report; genuinely malformed or non-standard reports may be repaired into something plausible but wrong, and the structured output gives no warning that this happened.
The service is explicitly not an official source for flight planning, so it cannot be used where a regulator requires an approved briefing source, regardless of how accurate it is.

Write the blind spot into the product. A statement that something “was not observed in AVWX REST 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: Free registration — an account or API key, at no cost

Register for a free token through the project's account portal and pass it with each request; the free tier is rate-limited and intended for light and development use, with paid tiers for production volume. Requests take a location as an ICAO identifier, an IATA code, or a coordinate pair, and the coordinate form is the reason many analysts prefer this over calling government services directly, because resolving a point to the nearest reporting station is otherwise a job you have to build. Options on the request control whether you receive translations, a summary, station information and speech-form output, and a format parameter offers alternatives to JSON. The important operational decision is whether to use the hosted service at all: the parsing engine is open source, so for high-volume or sensitive work you can pull raw reports from the government service and parse locally, which removes the rate limit, removes a third party from your data path and lets you pin a parser version for reproducibility. Use the hosted API for convenience and breadth; use the local engine when volume, privacy or reproducibility matters.

Licence

Two layers again. The parsing engine is open source under the licence in its repository, and running it yourself is straightforward. The hosted API is a commercial service with terms of use and tiered plans, and those terms govern redistribution and volume; check them directly rather than assuming that free access implies free redistribution. The underlying weather data is a third question and generally the least restrictive: METAR and TAF are products of national meteorological services exchanged internationally, and in many jurisdictions government weather output is public domain or openly licensed, though not universally – some national services assert rights over their data. The practical position for most analytical users is that using the observations internally is unproblematic, that republishing bulk parsed data is a question for the API terms, and that any claim about the data being official requires going to the issuing service. Do not represent AVWX output as an official meteorological product.

Rate limits and fair use

The free token carries a modest allowance sufficient for interactive work, development and low-volume enrichment; sustained pipeline use will exceed it. The efficient pattern is caching aligned to the data's own rhythm: METARs change on a roughly hourly cycle with amendments in between, so caching an observation for a fraction of an hour is safe and cuts request volume dramatically, while TAFs change only a few times a day and can be cached for hours. Never poll faster than the data updates – a request every thirty seconds against an hourly observation is pure waste and will exhaust your quota with no analytical gain. If your requirement is many stations continuously, the correct answer is either a paid tier or local parsing of a bulk government feed, not more aggressive polling. Set a descriptive user agent and back off properly on errors.

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 AVWX REST 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
METAR by station	JSON	cache 20 to 30 minutes; observations update roughly hourly with amendments	The default lookup for current conditions at a known aerodrome. Always keep the raw text alongside the parsed structure.
METAR by coordinate	JSON	as needed	Resolves a point of interest to the nearest reporting station. Record the distance to that station in the case, because it determines how much the report can be said to describe your location.
TAF by station	JSON	cache several hours	Forecast periods for planning context. Store the issue time and validity window explicitly so that a forecast is never mistaken later for an observation.
Station reference lookup	JSON	once; refresh quarterly	Airport metadata including position and identifiers. Small and stable, so mirror locally rather than querying repeatedly.
Local parsing with the open engine	bulk	continuous	Fetch raw reports from the government service and parse in your own environment. Removes quota, removes a third party from the data path, and pins a parser version for reproducible analysis.

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 the source as derived — Add AVWX in sources.php explicitly as a parsing layer over official meteorological output, so that anyone reading the catalogue understands the observation did not originate here and knows where the authority actually lies.
Resolve locations to stations first — In ingest.php, convert every point of interest to a station identifier and record the distance and bearing to it. This single stored field prevents the most common misuse of weather data in analysis.
Store raw and parsed together — Persist the raw report text alongside the structured fields. The raw text is the artefact of record and the only thing that lets you re-derive or challenge a parsed value later.
Normalise units at ingest — Convert visibility, wind and pressure to a single internal unit system immediately, keyed off the units field in the response, because mixed-unit weather data produces errors that are large, plausible and very hard to spot.
Separate observation from forecast — Store METAR and TAF in distinct structures with the forecast validity window attached, so that no downstream query can accidentally return a forecast period where an observation is expected.
Correlate with movement data — Use correlate.php to join conditions at the relevant aerodrome and time against ADS-B tracks and datalink messages, which is what turns anomalous flight behaviour into an explained event.
Attach to the case timeline — Push the conditions at the relevant place and time into timeline.php alongside the movement and reporting record, so that the environmental context sits on the same axis as the events it explains.
Alert on operationally significant conditions — Configure rules on derived flight rules category and on specific thresholds at watched aerodromes, so that conditions likely to cause diversions or ground stops are flagged before the movement anomalies appear.

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.

The upstream data is high quality by any standard: aerodrome observations are made to international specifications by trained observers or certified automated systems, and TAFs are issued by national meteorological services under regulatory obligation. The question specific to this source is therefore parser fidelity rather than data accuracy, and on that the record is good – the engine is mature, widely used and open to inspection, which is a much stronger position than a closed parser. The residual risks are concentrated in the awkward parts of the code form: non-standard remarks, regional variations, automated station qualifiers, and reports that are malformed at issue. The sanitised-versus-raw comparison is the practical quality signal, since a large repair delta indicates the parser worked hard and may have guessed. The derived flight rules field is an interpretation and should be treated as one; it is computed from visibility and ceiling by a documented rule, and where an operational conclusion rests on it you should verify against the underlying values. For anything evidential, go to the issuing meteorological service for a certified record, because a parsed convenience API is not a source of record however accurate its parsing.

Characteristic false positives

Coordinate lookup always returns something, so a query for a remote location silently returns conditions from a station far away across different terrain, and the response looks identical to one from a station on the spot.
A stale report served after a station outage looks exactly like a current one; unless you compare the report time to your query time on every use, you will treat hours-old conditions as present conditions.
Forecast periods read as observations. A TAF change group describes a conditional expectation, and quoting it as what the weather was is a category error that survives review because the text looks authoritative.
Units differ by region, and a visibility figure interpreted in the wrong unit is wrong by a factor of about sixteen hundred, which is large enough to invert an operational conclusion entirely.
Ceiling is derived, not reported: it is the lowest broken or overcast layer, and treating the lowest cloud layer of any coverage as the ceiling produces a systematically pessimistic and incorrect picture.
The parser repairs malformed reports, and a successful repair of a genuinely corrupt report yields structured values that are plausible, specific and wrong, with the sanitised field as the only clue.
Automated stations report what their sensors can see, which excludes some phenomena entirely, so an absence of thunderstorm or precipitation type in an automated report is not evidence that none occurred.
Remarks that are regionally standardised but not internationally so are returned as text, and a structured-only workflow will silently drop significant weather information that a human reader would have caught.

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

Weather ages faster than anything else in this catalogue and does so on a known schedule, which makes it manageable if you respect the schedule. A METAR describes a moment and is superseded roughly hourly, with special reports issued when conditions change significantly – meaning the interval between reports is itself informative, because a special report indicates something changed. A TAF is superseded by its scheduled reissue and by amendments, and an unamended TAF late in its validity period is much weaker evidence than a freshly issued one. The characteristic stale record is a report that is served from a station whose transmission has stopped: it keeps its original observation time and simply stops being replaced, so a pipeline that does not compare report time against wall clock will carry a fixed picture of the weather for hours. Set an explicit staleness threshold, treat anything beyond it as unknown rather than as current, and record both the report time and the retrieval time on every stored record so that a later reader can see the gap.

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

Aviation Intelligence

Serves these mission domains

Aviation Security

Yields these data points

How each sector uses AVWX REST 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

Weather is a planning input and this is a convenient way to get structured conditions at aerodromes worldwide, but it is not an approved operational source and should never displace the meteorological support your organisation is required to use. Its analytical value is in interpreting observed activity rather than in planning it: conditions at a base explain sortie rates, ground stops, diversions and the timing of movements visible in tracking data. Coverage gaps at military aerodromes are the key limitation, since the airfields of most interest frequently do not report internationally, and the nearest civil station may be meteorologically unrepresentative.

🕵 National intelligence

The routine use is explaining anomalies. A track that holds, diverts, climbs unusually or departs at an odd hour is far more often weather than anything else, and having structured conditions at the relevant field and time closes those questions cheaply before analytical effort is wasted. Weather also constrains other collection: visibility and cloud cover determine whether an optical satellite pass or a ground observation could have seen what a report claims, which makes this a plausibility check on human and imagery reporting. Coordinate-based lookup is the feature that makes this practical against arbitrary locations rather than only against airports you already know.

👮 Law enforcement

Investigative reconstruction is the main use – what were the conditions at a location at the time of an incident, and did they support what a witness or a suspect claims. For that purpose, note two things: this API is oriented to current conditions rather than to archives, so historical reconstruction usually belongs to the government archive service, and any weather evidence going to court should be a certified record from the national meteorological service rather than a parsed API response. Use this for investigative direction and obtain the formal record for the file.

🔍 Private investigation and corporate security

Useful in accident, insurance and liability work for establishing environmental context quickly, and in surveillance planning for judging whether conditions supported an observation. The professional caution is the same as for law enforcement: an API response is not a certified record, and opposing counsel will make that point. Establish the picture here, then request the formal observation record from the meteorological service for anything that will be relied on. Be careful with coordinate lookups in complex terrain, where the nearest station can be genuinely unrepresentative of a location a few kilometres away.

📰 Journalism and OSINT media

A fast, structured way to verify or refute weather claims in reporting – whether conditions supported a described event, whether a flight delay explanation is plausible, whether visibility allowed a claimed sighting. It is far more reliable than consumer weather sites because it carries the actual aviation observation rather than a modelled forecast for a postcode. In publication, cite the issuing meteorological authority rather than the parsing API, note the station and its distance from the location in question, and distinguish clearly between an observation and a forecast, because the two are routinely conflated in coverage.

🌍 NGO, humanitarian and human rights

Humanitarian air operations, disaster response and access planning all need aerodrome conditions in places where consumer weather services are unhelpful, and structured METAR and TAF for the actual field being used is exactly the right product. The limitation is that the fields most relevant to humanitarian access – austere strips, unlicensed fields, damaged airports – frequently do not report at all, so the nearest reporting station may be a long way off. Record that distance in the assessment, use forecast products for planning and observations for reporting, and never present either as an official briefing.

🎓 University and research

Convenient for teaching, for prototyping and for research where structured aviation weather is an input rather than the object of study. For research proper the recommendation is to work from the government archives, which offer long records with documented quality control, and to run the open-source parser locally with a pinned version so that results are reproducible. Using a live third-party API in a published methodology creates a reproducibility problem, because the same query next year may return a differently parsed result and there is no version to cite.

Playbook: working AVWX REST 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 — Decide whether you need weather or you need an explanation

Most analytical uses of aviation weather are not about the weather; they are about explaining an observed behaviour. Frame the question that way and you will query the right station at the right time. Framing it as let me get the weather produces reports for the wrong place and hour that then get used anyway.

Phase 2 — Resolve the location to a station and keep the distance

Convert your point of interest to a reporting station and record how far away it is and in what terrain. This number determines how much weight the report can carry. A station five kilometres away across flat ground is representative; one forty kilometres away over a ridge is a different climate.

Phase 3 — Fix the time before you fix the place

Establish the exact UTC window you care about, then find the reports that bracket it. Aviation weather is a sequence of point-in-time observations, and the report you want is often the one immediately before your event rather than the current one.

Phase 4 — Separate observation from forecast explicitly

Decide for each question whether you need what happened or what was expected. Both are legitimate – a diversion decision made on a forecast is explained by the forecast, not by what actually occurred – but the two answer different questions and mixing them produces incoherent narratives.

Phase 5 — Read the raw report, not only the parsed fields

Open the raw text at least once for any report that matters. Remarks, regional conventions and observer notes carry information the structured output does not, and comparing raw against sanitised tells you how much repair the parser performed.

Phase 6 — Normalise units before comparing anything

Visibility in statute miles and visibility in metres are both correct and are not comparable. Convert on ingest using the units field, and never compare two stations' figures without confirming both went through the conversion.

Phase 7 — Derive ceiling correctly

Ceiling is the lowest broken or overcast layer, not the lowest layer of any coverage. Getting this wrong changes the flight rules category and therefore any operational conclusion drawn from it. If a conclusion rests on the derived category, verify it from the underlying visibility and cloud layers.

Phase 8 — Correlate against the movement picture

Overlay conditions at the relevant aerodromes on the flight tracks and datalink traffic in your case. Holds, diversions, go-arounds, ground stops and unusual routings resolve to weather in the large majority of cases, and closing those questions early stops analysts pursuing them as anomalies.

Phase 9 — Use weather as a constraint on other sources

Cloud cover and visibility determine what optical imagery could have captured and what a ground observer could have seen. This makes weather a cheap plausibility test on imagery-based and human reporting, and it is one of the more underused moves in open-source analysis.

Phase 10 — Escalate to the authority for anything evidential

If a weather fact will appear in a legal filing, a formal report or a published allegation, obtain the certified record from the national meteorological service. A parsed convenience API is a research tool. Doing this early is much cheaper than doing it under challenge.

Phase 11 — Manage staleness as a first-class concern

Compare report time to retrieval time on every use and set a threshold beyond which the answer is unknown rather than current. Station outages present as a report that simply stops being replaced, and a pipeline without this check will report yesterday's conditions indefinitely.

Phase 12 — Decide hosted versus local deliberately

For occasional lookups, use the hosted service. For continuous pipeline enrichment, sensitive work, or anything that must be reproducible, run the open parser against government feeds locally. That decision affects quota, privacy and reproducibility simultaneously and should be made once, explicitly.

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
NOAA Aviation Weather Center	supersedes	The authoritative upstream for much of this data, with broader product coverage including hazard products, and no key required.
National meteorological services	supersedes	The issuing authorities. Certified records for evidential use come from them, not from any parsing layer.
Iowa Environmental Mesonet	extends	Long-run archived surface and aviation observations, which is what retrospective reconstruction actually needs since this API is oriented to current conditions.
OpenSky Network	corroborates	The movement data that weather explains. Correlating conditions against tracks is where this source earns its place in an intelligence pipeline.
Airframes.io	corroborates	Weather-related datalink traffic and diversion messages make sense only against actual conditions, and conversely conditions explain the operational messages.
hexdb.io	prerequisite	Resolves airport identifiers and coordinates needed to select the right reporting station for a location of interest.
OurAirports	extends	Open airport reference data for identifying candidate stations and understanding which fields exist near a location even when they do not report weather.

Legal, ethical and operational constraints

The constraints here are unusually light and one of them is unusually important. Weather observations are not personal data and carry no privacy dimension, so the data-protection considerations that dominate most sources in this catalogue do not apply. The licensing position is layered – open-source engine, commercial API terms, and national meteorological services with varying positions on their own data – and internal analytical use is unproblematic while bulk redistribution needs checking against the API terms and the upstream service's position. The important constraint is a safety one: this is explicitly not an approved source for operational flight planning, and in most jurisdictions regulators require pilots and dispatchers to use official briefing sources. Do not build anything that could be mistaken for an operational briefing tool, do not present its output as an official meteorological product, and if your organisation conducts or contracts flight operations, keep this firmly on the analytical side of the line. For evidential use, obtain a certified record from the issuing service.

Operational security

The exposure is small but not zero. Requests carry an API token tied to an account, so the operator of the service can see which locations and times your organisation is interested in, and a pattern of queries against one remote aerodrome is a legible statement of interest in that place. Weather queries are also unusually revealing in aggregate because they tend to be tightly coupled to real operational or investigative interest – people do not idly look up conditions at obscure airfields. If the geography of your interest is sensitive, query a wider set of stations than you need, cache so that repeated interest never leaves your network, or run the open-source parser locally against a bulk government feed, which removes the third-party observer entirely. The local option is more practical here than for most sources in this catalogue precisely because the engine is open and the upstream data is free.

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 AVWX REST API is contributing anything, and they are worth baselining now so the answer is available later.

Median age of weather records at the moment they are used in analysis, which is the direct measure of whether your caching and staleness handling are working.
Distance from the point of interest to the resolved reporting station, tracked across cases, since a rising median means your questions are drifting away from where the network can answer them.
Proportion of correlated flight anomalies that were explained by conditions, which tells you how much analyst time this source is saving on questions that were never anomalies.
Parser repair rate, measured as the share of reports where sanitised differs materially from raw, as an early indicator of upstream data problems or unusual regional conventions.
Rate of queries returning no station within a usable distance, which is an honest measure of coverage against your actual areas of interest rather than against the world.
Quota consumption against unique station-hours retrieved, which distinguishes efficient caching from wasteful polling of data that only changes hourly.
Count of findings where weather constrained or refuted a claim from another source, which is the most valuable and least obvious contribution this source makes.

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:

Weather explains flight behaviour more often than intent does. Before treating a hold, a diversion, an unusual altitude or an odd departure time as significant, check the conditions. Analysts who skip this step generate a steady stream of anomalies that are simply weather.
A report is a point observation, and coordinate lookup hides that. Always record how far the answering station is from your location and whether the terrain between them makes the report representative.
Forecast and observation are different claims. A TAF explains a decision made in advance; a METAR describes what happened. Both are useful, and using one where the other is meant produces narratives that do not survive scrutiny.
Ceiling is derived from broken or overcast layers only. Getting this definition wrong silently changes the flight rules category and therefore every operational inference built on it.
Units are regional and the error is enormous. Read the units field on every response and normalise on ingest; a visibility figure misread between miles and metres is not a small error.
Compare raw against sanitised when it matters. A large repair delta means the parser reconstructed a malformed report, and the confident structured output may be a guess dressed as a measurement.
Automated stations cannot see everything. The absence of a phenomenon in an automated report is not evidence of its absence, which matters when weather is being used to refute a claim rather than to support one.
Use weather to constrain other sources. Cloud and visibility determine what optical imagery and ground observers could have seen, which makes this a cheap and underused test of reporting plausibility.
For anything evidential, go to the meteorological authority. A parsing API is a research accelerator; the certified observation record is the artefact that survives challenge, and obtaining it early costs far less than obtaining it under pressure.

Questions analysts actually ask

Is this an official weather source?

No. It is a parser and delivery layer over data issued by national meteorological services. It is not an approved source for flight planning, and it should not be presented as an official meteorological product. For anything operational or evidential, use the issuing authority.

Why does a coordinate lookup return a station far from my point?

Because it returns the nearest station that reports, and in many parts of the world that can be a long way off. The service will not warn you that the answer is unrepresentative. Always capture the distance and consider the terrain before using the report as conditions at your location.

What is the flight rules field and can I rely on it?

It is a derived category computed from visibility and ceiling using a documented rule, not something the observer reported. It is a good summary and a poor foundation. Where a conclusion depends on it, check the underlying visibility and cloud layers yourself.

Can I use this for historical weather reconstruction?

Not really. The service is oriented to current and forecast conditions. Retrospective work belongs to government archives of surface and aviation observations, which hold long records with documented quality control and are the right source for reconstructing conditions at a past time.

Why is a station returning nothing?

Several possibilities: the aerodrome does not report internationally, it reports only during operating hours, the station has failed, or transmission is delayed. The response cannot distinguish them. Check whether nearby stations are reporting normally before concluding anything about that location.

Should I use this or call the government service directly?

Use this when you value the parsing, the coordinate lookup and the consistent structure, which is most interactive and investigative work. Call the government service directly, and parse locally with the open engine, when you need volume, reproducibility, or no third party in your data path.

How long can I cache a report?

Align caching to the data's rhythm. Observations update roughly hourly with special reports in between, so caching for a fraction of an hour is safe and hugely reduces request volume. Forecasts change a few times daily and can be cached for hours. Polling faster than the data changes buys nothing.

Can weather data help verify claims from other sources?

Yes, and this is one of its most useful roles. Cloud cover and visibility constrain what optical imagery could have captured and what a ground observer could have seen, so weather is a cheap plausibility test on imagery-derived and human reporting that is applied far less often than it should be.

Does the parser ever get it wrong?

It handles standard reports very well and struggles at the margins – malformed reports, unusual regional remarks, non-standard groups. Its repair of a corrupt report can produce confident, specific, wrong values. The sanitised-versus-raw comparison is your signal, and keeping the raw text means you can always re-derive.

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 code forms for aerodrome observations, defined in the WMO manual on codes and mandated for aviation use through ICAO Annex 3.
TAF is the international aerodrome forecast code form, with defined validity periods and change indicators whose conditional semantics are frequently misread.
ICAO Annex 3 governs meteorological service for international air navigation and is the reason these products exist in a comparable form worldwide.
ICAO four-letter location indicators identify reporting stations and are the join key between weather data and airport reference datasets.
IWXXM is the XML and GML exchange format that national services increasingly use alongside the traditional alphanumeric code forms, and it is the direction of travel for machine-readable aviation weather.
Flight rules categories are operational classifications derived from visibility and ceiling rather than meteorological observations in their own right, and the thresholds are regulatory rather than physical.
The platform exports weather context attached to aircraft, airport and event entities in STIX 2.1, MISP, CSV, JSON and JSONL alongside the observations 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.

AVWX REST API — AVWX. The service, its endpoints, options and current plan structure. The reference for what the hosted API actually offers today.
AVWX account portal — AVWX. Where the free token is issued and where plan limits are managed. Start here before writing any integration.
avwx-engine — AVWX. The open-source parsing engine. Read it to understand exactly how each field is derived, and run it locally when you need volume or reproducibility.
NOAA Aviation Weather Center — NOAA. The authoritative upstream for a large share of this data, with hazard products this API does not cover and no key requirement.
National Centers for Environmental Information — NOAA. The archival route for historical surface and aviation observations, which is what retrospective reconstruction requires.
Iowa Environmental Mesonet — Iowa State University. Practical archived access to long runs of METAR data, widely used for reconstructing conditions at a past date and time.
International Civil Aviation Organization — ICAO. Annex 3 and the location indicator system that define what aviation weather products are and how stations are identified.
World Meteorological Organization — WMO. Custodian of the code forms behind METAR and TAF and of the international exchange arrangements that give this data global coverage.
Federal Aviation Administration — FAA. Regulatory context for what constitutes an official weather briefing source, which is the constraint that keeps this API on the analytical side of the line.

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 resolves points of interest to reporting stations with the distance recorded, stores raw alongside parsed reports, normalises units at ingest, and correlates conditions against flight tracks so that weather-explained anomalies never reach an analyst as anomalies.. Browse the full source catalogue, or follow any tag above into the rest of the library.