When WeatherAPI.com fits
An app accepting city names, postal codes or coordinates and needing a compact location-and-forecast response.
Check before integrating
Forecast length and historical access change by plan. Validate the requested horizon against the plan rather than the largest number mentioned in the documentation.
Provider endpoint reference
This is WeatherAPI.com's documented interface. Its credentials and response format are separate from an All Them APIs account.
GET https://api.weatherapi.com/v1/forecast.json
Authentication: API key in key
Inputs: key, q, days; optional aqi and alerts
Output: JSON location, current conditions and forecast.forecastday entries.| Capability | What to expect |
|---|---|
| Forecast interface | Dedicated forecast endpoint with a days parameter |
| Historical workflow | History endpoint; lookback depends on plan |
| Location input | City, postal code, coordinates and other q formats |
| Response shape | JSON or XML; location/current/forecast objects |
| Production access | Call allowance and feature tier |
| Cost driver | Monthly request allowance |
Pricing model and production access
Monthly plans with call allowances. The pricing page lists a $7/month Starter plan with 3 million calls and a seven-day forecast; other capabilities remain plan-specific. Checked October 28, 2026.
For 10,000 location-day lookups, record the requested variables and hourly/daily resolution first. A plan counting calls and a plan counting returned weather records can charge different amounts for the same HTTP request count.
Migration notes
Resolve ambiguous city names before comparing results. Convert forecastday/hour objects and local timestamps to your application's canonical hourly schema.
Keep provider-specific authentication and response mapping inside an adapter. Preserve source timestamps and identifiers so changing a provider does not silently change the meaning of stored records.
WeatherAPI.com alternatives
| Alternative | When to evaluate it |
|---|---|
| WeatherAPI.com vs OpenWeather | An application combining current weather, forecast intervals and alerts through a documented product family. |
| WeatherAPI.com vs Open-Meteo | A team choosing explicit weather variables or comparing model output rather than consuming a fixed weather-card payload. |
| WeatherAPI.com vs Tomorrow.io | A workflow connecting weather fields to operating decisions, where the required fields and forecast intervals can be specified in advance. |
| WeatherAPI.com vs Visual Crossing | Historical weather joins, reporting and backfills that benefit from a consistent date-range interface. |
| WeatherAPI.com vs Weatherbit | An integration with a fixed daily forecast schema that may later need air-quality, agriculture or energy data. |
A fair evaluation
- Fix ten coordinates across your actual service area. Use the same UTC issue time, units and hourly window for every provider.
- Save the forecast before the event. Compare later against an agreed observation source; a successful HTTP response does not establish forecast accuracy.
- Check missing values, elevation, timezone boundaries and precipitation accumulation periods before calculating an error statistic.
- Measure p50/p95 request latency, throttling and billed units separately from forecast error. Repeat across several weather conditions.
- Confirm caching, attribution, redistribution and commercial-use terms for the exact plan. A keyless endpoint is not automatically a commercial entitlement.
A common integration contract
POST /api/v1/weather/forecastReview the request contract and tell us the coverage you need. Access requires enablement; this endpoint does not execute or bill requests yet.
View endpoint and request accessSources and review dates
Documentation reviewed October 28, 2026. These are integration and plan comparisons, not measured speed or accuracy rankings. Availability, licensing and prices should be confirmed for the chosen plan.
Corrections: email faizank@docsalot.dev with an official source.