Skip to content
VERTEXAPI

Open-Meteo migration

/v1/forecast keeps Open-Meteo’s parameter names and response shape on purpose. If you have working Open-Meteo code, change the base URL and add a key.

Identical

Section titled “Identical”
  • latitude/longitude comma lists, hourly, current, daily, models, temperature_unit, wind_speed_unit, precipitation_unit, timezone (including auto), timeformat, forecast_days, forecast_hours, start_hour/end_hour, elevation.
  • Response keys: latitude, longitude, elevation, utc_offset_seconds, timezone, timezone_abbreviation, generationtime_ms, hourly_units, hourly, current_units, current, daily_units, daily. Time arrays first, one array per field, null for missing.
  • Standard field names and units: temperature_2m, wind_speed_10m, precipitation, cloud_cover_low, snowfall in cm, snow_depth in m, and so on. Older spellings (windspeed_10m, cloudcover) still work.
  • Several models suffix fields with _model.
  • Call accounting: one call per location per ten variables.

Extra

Section titled “Extra”
  • Fields: wstar, hcrit, top_of_lift, cloud_base, cu_depth, smoke, us_aqi, winds aloft every 1,000 ft. See Point forecasts.
  • Models: hrrr and rrfs at 3 km with the full soaring set; Open-Meteo’s ncep_hrrr_conus and other slugs are accepted as aliases.
  • model, model_run, model_run_extended, model_elevation in the body.
  • format=csv, dry_run=1, and cost headers on every response.
  • Everything beyond forecasts: profiles, tiles, observations, text products, outdoor layers.

Different

Section titled “Different”
  • Coverage is CONUS. Points outside the box return 400.
  • No history yet. past_days, past_hours, start_date, end_date return 400 rather than data. An archive has been kept since September 2026 and history is on the roadmap.
  • Default model is hrrr, not a seamless blend. best_match resolves to hrrr.
  • The series starts at the current model run, not at local midnight; use forecast_days or start_hour to trim.
  • timezone=auto is a CONUS approximation by longitude bands with Arizona handled; pass an IANA name where county-level accuracy matters.
  • Auth is required on every route, with a Bearer header or apikey parameter.
  • minutely_15, ensemble, marine, air_quality (beyond smoke), flood and geocoding are not offered.

Client libraries

Section titled “Client libraries”

The official Open-Meteo SDKs (openmeteo-requests for Python, @openmeteo/sdk for TypeScript, and the Swift, Kotlin, Go and Rust clients) work by pointing their URL at https://api.vertexmaps.com/v1/forecast and passing apikey. They request format=flatbuffers, which the API serves in the same schema; see FlatBuffers for how variables are identified. Anything that builds URLs against the Open-Meteo forecast endpoint, from Home Assistant integrations to LangChain tools, works the same way.

import openmeteo_requests


om = openmeteo_requests.Client()
params = {"latitude": 46.87, "longitude": -113.99,
          "hourly": ["temperature_2m", "wind_speed_10m"], "timezone": "auto"}


# before
responses = om.weather_api("https://api.open-meteo.com/v1/forecast", params=params)
# after
responses = om.weather_api("https://api.vertexmaps.com/v1/forecast",
                           params={**params, "apikey": "vtx_live_…"})

Errors come back Open-Meteo style too, as {"error": true, "reason": "…"} with a 400, so the SDKs raise their usual exception.