What is METAR.ws?
Keep observation time separate from the time the service received a report. Decoded temperature, wind, visibility and flight category accompany the raw text; station coordinates and elevation help align the observation site with a model grid. Grid-point distance and source age add freshness context.
Model highs and lows are forecasts, not measured settlement results. Model output can be detected, partial or day-complete, and source publication and model-run timing bound availability. Match the contract's station, time zone, units and rounding convention before comparing a forecast extreme with the eventual observation.
Who it is for
- Building weather-market monitors as a developer.
- Comparing forecasts with station observations.
- Integrating station data with source timestamps.
Feed coverage and updates
- Decoded observations
Receive temperature, wind, visibility and flight category together with the raw report.
- Separate timestamps
Distinguish observation time from platform receipt time.
- Station metadata
Use coordinates and elevation when aligning stations and model grids.
- Model signals
Receive derived highs and lows as model runs become available.
- Model lifecycle events
Handle detected, partial and day-complete output as distinct states.
- Freshness context
Inspect grid-point distance and source age.
- Historical API
Retrieve past METAR/SPECI data within the selected plan's limits.
- WebSocket subscriptions
Select stations and event types over an authenticated connection.
Monitoring and data workflows
Monitor a weather contract
Match its settlement station and units, then subscribe to the relevant observation events.
Compare model runs
Store the model, run time, freshness and forecast extreme alongside the eventual observation.
Audit report timing
Compare observation and receipt times rather than treating every newly received report as a new measurement.
Pricing and total cost
EUR plans separate sandbox testing, a limited station set and broader production access. Observation and station entitlements differ by plan; model testing should not be treated as unrestricted observation access.
Sandbox
Free
- 1 API key
- 1 WebSocket connection
- Model testing across stations
- Historical API: 1 request/second
Starter
€49/month; 7-day trial
- 10 stations
- 2 WebSocket connections
- 1 API key
- Historical API: 10 requests/second
Professional
€199/month
- All stations
- 5 API keys
- 10 WebSocket connections
- Historical API: 100 requests/second
Feed access and configuration
- Check coverage for the required station and model.
- Create an API key.
- Connect to the documented WebSocket endpoint.
- Subscribe to the station identifiers and event types you need.
- Retain raw reports, units and both timestamps.
- Handle partial model runs and reconnections explicitly.
Useful links
What to check
- The reference station, time zone and rounding convention must match the contract rule.
- Sandbox and paid plans have different observation and station entitlements.
- Source publication and model-run timing limit when data becomes available.
A closer look
Ratings & reviews
User reviews 0
The main score switches to user ratings after 5 published reviews.
A specific example helps the next person choose the right tool.
Related tools
Browse categoryFrequently asked questions about METAR.ws
Does it include raw METAR text?
Yes. Raw reports accompany the decoded fields.
Do I need to parse GRIB files myself?
The model product supplies derived station-level signals.
Is historical data available?
Yes. It is provided through an API with rate limits.
Why retain both timestamps?
They distinguish when the observation occurred from when the service received it.


