Research · We checked 13 public APIs against their own OpenAPI specs. 9 had hard mismatches.· Markdown

Open-Meteo forecast API: spec vs live

Summary

Spec: https://raw.githubusercontent.com/open-meteo/open-meteo/main/openapi/forecast.yml (OpenAPI 3)
Base URL: https://api.open-meteo.com
Run: 2026-10-30, read-only GET requests, no credentials
Coverage: 1 operations in the spec, 1 requests sent, 1 successful,1 operations observed
Hard violations: 0 distinct schema locations
Reviewer note: Minor: current_units.interval is undocumented.

Other body findings 1

Undocumented fields and loose constraints on successful responses. Documentation gaps, not violations.

Hide 1 finding

bodyresponse-undocumented-propertyinfo

GET /v1/forecast > response 200 > application/json > /current_units/interval

response body at /current_units/interval: property "interval" is not documented

GET /v1/forecast?azimuth=0&current=temperature_2m&daily=temperature_2m_max&forecast_days=7&hourly=temperature_2m&latitude=52.52&longitude=13.41&past_days=0&precipitation_unit=mm&temperature_unit=celsius&tilt=0&timeformat=iso8601&wind_speed_unit=kmh → 200 application/json; charset=utf-8

actual "interval"

If the spec is the source of truth: Stop returning "interval" from GET /v1/forecast if it is not part of the contract.
If the implementation is the source of truth: Add "interval" to paths["/v1/forecast"].get.responses["200"].content["application/json"].schema.properties["current_units"].properties.

Data

Findings JSON: every finding on this page with its classification and fixes.
Observations JSON: every request sent and the status it received.
Reproduce with apidrifter run; the target definition is in tools/survey/targets.json in the repository.

If a finding is wrong, open an issue; if it is right, a pull request on the spec is welcome.