Feature spec
BeginnerCategory
vertical-tools
Build with AI
1–3 hours with V0 or Lovable
Custom build
2–5 days custom dev (including caching layer)
Running cost
$0/mo with Open-Meteo · $0–50/mo with OpenWeatherMap at scale
Works on
Everything it takes to ship a Weather Forecast Integration — parts, prompts, and real costs.
A weather integration needs three pieces: a location input (browser geolocation or city search), a server-side proxy that keeps your API key secret, and a UI layer for current conditions plus a 7-day forecast. With V0 or Lovable you can ship a working weather widget in 1–3 hours for $0/month using Open-Meteo (free, no key needed) or within OpenWeatherMap's 1,000 calls/day free tier.
What a Weather Forecast Integration Actually Is
A weather integration connects your app to a third-party weather API — OpenWeatherMap, Open-Meteo, or Tomorrow.io — and displays conditions for a location the user specifies or their browser detects automatically. The feature appears in travel apps, outdoor event planners, agriculture dashboards, food delivery apps (courier routing), and any product where conditions affect what users do next. The challenge isn't displaying temperature — AI tools do that in minutes. The real decisions are: which API to use (free vs. paid, accuracy vs. cost), how to cache responses so you don't burn your quota on repeated page loads, and where to keep the API key so it's never visible in the browser network tab.
What users consider table stakes in 2026
- Current conditions shown immediately on page load — temperature, humidity, wind speed, and a weather icon — without requiring the user to search first
- 7-day forecast with each day's high/low temperature and precipitation probability displayed in a scannable row
- Hourly breakdown for the next 24–48 hours as a scrollable timeline or sparkline chart
- Browser geolocation detection on first visit with a visible city search fallback for users who deny location permission
- °C/°F and km/h vs. mph toggle that flips all displayed values simultaneously with no reload
- Loading skeleton while the API call is in flight, and a clear error state with a retry button when the API is down or offline
Anatomy of the Feature
Six components — the API proxy is the one AI tools most often skip, and skipping it is the security failure mode for this feature.
Location input and geocoding layer
ServiceConverts a city name or postcode to latitude/longitude coordinates so the weather API can return accurate data. Uses the browser's navigator.geolocation.getCurrentPosition() for automatic detection, or the Mapbox Geocoding API / OpenWeatherMap Geocoding API for city name searches. Geocoding result is held in component state — no database needed.
Note: navigator.geolocation is blocked in the Lovable preview iframe and in V0's sandbox — geolocation testing requires the published or deployed URL.
Server-side API proxy
BackendA Next.js API route (app/api/weather/route.ts) or Supabase Edge Function that receives a lat/long from the frontend, appends the secret API key from environment variables, calls the weather API, and returns the cleaned JSON. This is the only place the key exists — it never touches the browser.
Note: This is the component AI tools skip most often. Lovable tends to call the weather API directly from the React component. Always verify the key is server-side before publishing.
Caching layer
BackendCache-Control headers on the API route response (s-maxage=900, stale-while-revalidate=1800) tell Vercel's Edge Cache to serve cached weather data for 15 minutes before re-fetching. For multi-region or high-traffic apps, Upstash Redis stores cached responses keyed by rounded coordinates (1 decimal place) to avoid blowing the API quota.
Note: Without caching, 1,000 users checking weather on page load each day will exhaust the OpenWeatherMap free tier in minutes. A 15-minute cache drops that to ~96 API calls per day per unique location.
Current conditions card
UIA shadcn/ui Card component showing temperature, condition description, humidity percentage, wind speed, and feels-like temperature. Animated or static SVG weather icons from the Meteocons package or animated-weather-icons npm package provide instant visual context. Light/dark mode variants should swap icon colors automatically via Tailwind dark: classes.
Note: Meteocons is free and open-source — include it as a local SVG set rather than a CDN link to avoid CORS issues.
Forecast timeline
UIHourly forecast displayed as a horizontally scrollable row using shadcn/ui ScrollArea — each item shows time, icon, and temperature. 7-day forecast shown as a vertical list or CSS grid with min/max temps and precipitation probability percentage. A Recharts AreaChart or LineChart overlays the temperature trend for the next 48 hours.
Note: The Recharts ResponsiveContainer must have an explicit height (e.g., height={200}) — leaving it as 100% inside a flex parent collapses to zero height.
Unit preference store
DataUser preference for temperature unit (°C or °F) and wind speed unit stored in localStorage on the client. A React context or Zustand store exposes the current unit preference to all components. No database or authentication required — unit preference is purely local.
Note: localStorage access during SSR causes a Next.js hydration mismatch. Always initialize the unit state in a useEffect hook or inside a 'use client' component.
Build it — pick your path
Each tool fits this feature differently. Switch tabs to compare fit, time, the exact steps, and a copy-paste prompt.
Best path for weather integration — V0 naturally generates a Next.js API route that keeps the key server-side, and Recharts temperature charts are a V0 strength. Vercel Edge Cache handles caching automatically on deploy.
Step by step
- 1Paste the prompt below into V0 and let it generate the weather page, API route, and Recharts chart components
- 2Open the Vars panel in V0 and add OPENWEATHERMAP_API_KEY (or leave blank if using Open-Meteo which needs no key)
- 3Publish to Vercel — test geolocation and the unit toggle on the live HTTPS URL from your phone
- 4In Vercel Dashboard, confirm the API key is set as an environment variable and not in any client-side file
Build a weather forecast page for a Next.js app using the OpenWeatherMap One Call API 3.0 (or Open-Meteo as a fallback if no key is available). The API key must be stored in OPENWEATHERMAP_API_KEY server-side — never in client code. Create a Next.js API route at app/api/weather/route.ts that accepts lat and lon query params, fetches the weather data server-side, adds Cache-Control: s-maxage=900, stale-while-revalidate=1800 to the response headers, and returns current conditions plus 7-day and hourly forecast. On the frontend: use navigator.geolocation.getCurrentPosition() to detect location on page load; if denied or unavailable, show a city search input that uses OpenWeatherMap Geocoding API to resolve lat/long. Display: (1) a current conditions card with temperature, condition description, humidity, wind speed, and a weather icon using Meteocons SVGs; (2) a horizontally scrollable hourly row for the next 24 hours using shadcn/ui ScrollArea; (3) a 7-day forecast grid with daily high/low and precipitation probability; (4) a Recharts AreaChart for 48-hour temperature trend. Include a unit toggle (Celsius/Fahrenheit, km/h / mph) stored in localStorage via a useEffect hook — never access localStorage during SSR. Show three distinct states: loading skeleton, data loaded, error with retry button. Handle geolocation denied gracefully with a fallback city search input.
Where this path bites
- V0 does not auto-provision Vercel env vars — you must add OPENWEATHERMAP_API_KEY manually in the Vercel Dashboard before the API route will return data
- The V0 sandbox cannot access the browser geolocation API — test the full location flow on the deployed Vercel URL
- Recharts may need a follow-up prompt to fix ResponsiveContainer height collapse inside flex layouts
Third-party services you'll need
Weather data itself ranges from completely free to premium. Pick based on the accuracy your use case actually needs — most apps are well-served by the free options.
| Service | What it does | Free tier | Paid from |
|---|---|---|---|
| Open-Meteo | Current conditions + hourly + daily forecast; free alternative to OpenWeatherMap with no API key required | Free for commercial use up to 10,000 calls/day | Free (no paid tier — donation-supported) |
| OpenWeatherMap One Call API 3.0 | Current conditions + hourly + daily forecast; most widely documented API for web weather widgets | 1,000 calls/day | $40/mo for 100,000 calls/day (approx) |
| Tomorrow.io | Richer weather data including air quality, pollen count, UV index, and minute-level precipitation | 500 calls/day | From $150/mo (approx) |
| Mapbox Geocoding API | Converts city names or addresses to lat/long coordinates for the location search input | 100,000 requests/mo | $0.75/1,000 requests above free tier |
| Upstash Redis | Edge-compatible Redis cache for weather API responses — keeps frequently requested locations fast and within free API tier limits | 10,000 requests/day | From $10/mo |
Swipe the table sideways to see pricing.
What it costs to run
Drag through the tiers to see how your monthly bill scales with users — no surprises later.
Estimated monthly running cost
Open-Meteo is completely free with no API key. With 15-minute caching, 100 users generate a tiny fraction of the 10,000 daily call limit. No database or auth required.
Estimates use verified 2026 pricing and assume typical usage per user. Your real bill depends on activity, storage, and third-party plans.
What breaks when AI tools build this
The failures people actually hit on their first build — the symptom, why it happens, and the exact fix.
Weather API key is visible in the browser Network tab
Symptom: Lovable AI frequently generates the weather fetch call directly inside the React component — the API key appears in the request URL visible to any user who opens DevTools. This is the most common and most dangerous mistake for this feature. The key can then be scraped and used to exhaust your API quota.
Fix: Move every weather API call to a Next.js API route (V0) or Supabase Edge Function (Lovable). Store the key in OPENWEATHERMAP_API_KEY server-side. After any AI generation session, open the published app's Network tab and verify no calls go directly to api.openweathermap.org — all calls should hit your own /api/weather endpoint.
Geolocation prompt never fires in preview
Symptom: navigator.geolocation.getCurrentPosition() is blocked inside Lovable's preview iframe and V0's sandbox environment. The call returns silently with no error, leaving location as null. Builders assume geolocation is broken in their code when it's actually the environment blocking it.
Fix: Test geolocation exclusively on the published Lovable URL or deployed Vercel URL opened in a real mobile or desktop browser. Always include a city name search input as the non-permission fallback — a significant share of real users deny location access.
localStorage unit toggle causes hydration mismatch in Next.js
Symptom: When V0 generates the Celsius/Fahrenheit toggle, it often accesses localStorage to read the saved preference during the initial render. Next.js runs components server-side where localStorage doesn't exist, so the server renders one state and the client hydrates with a different value — React throws a hydration error.
Fix: Initialize the unit state as a static default ('celsius') and read localStorage only inside a useEffect hook: useEffect(() => { setUnit(localStorage.getItem('tempUnit') || 'celsius') }, []). Alternatively, wrap the entire unit toggle component in a 'use client' boundary with useEffect initialization.
Weather data is stale — showing yesterday's forecast
Symptom: Without explicit cache invalidation, Vercel's CDN may serve the same cached API response indefinitely once it's been cached. Users see forecast data hours or even a day old, which destroys trust in the feature instantly.
Fix: Set Cache-Control headers on every weather API route response: Cache-Control: s-maxage=900, stale-while-revalidate=1800. This tells Vercel's Edge Cache to serve fresh data after 15 minutes and treat data up to 30 minutes old as stale-while-revalidating. Explicitly include this header in your prompt — V0 does not add it by default.
Best practices
Always proxy weather API calls through a server-side route or Edge Function — never call a weather API with a key from frontend code
Default to Open-Meteo for apps where budget matters — it's completely free for commercial use, no API key required, and the data quality matches OpenWeatherMap for most use cases
Cache responses for 15 minutes minimum using Cache-Control headers; most users don't need real-time weather data and caching cuts API costs by 90%+
Round user coordinates to one decimal place (about 11km precision) before using them as cache keys — this collapses nearby users onto the same cached response
Always ship a city name search fallback alongside geolocation — at least 30% of desktop users and some mobile users deny the location prompt
Show a loading skeleton for the weather card, not a spinner — weather data takes 200–800ms to arrive and a skeleton reduces perceived wait time
Test the error state deliberately by temporarily pointing the API route at a bad URL — verify the retry button is visible and functional before shipping
When You Need Custom Development
A basic weather widget is a one-session AI build. These use cases reliably outgrow what prompt-and-publish produces:
- App needs weather-triggered push notifications (e.g., 'Rain tomorrow morning — bring a jacket') with user-configured thresholds per location — requires a background job, a user location store, and a push delivery pipeline
- Agricultural or field operations requiring hyper-local data at sub-kilometer resolution — Tomorrow.io's field-level API and soil moisture feeds require custom data modeling and paid plan negotiation
- Multi-location weather dashboard with custom widget layouts, saved locations per user, and comparative views — the state management and data fetching architecture for 10+ concurrent location widgets exceeds AI tool output quality
- Historical weather data queries for analytics, compliance, or retrospective reporting — Tomorrow.io Historical API returns petabytes of structured data that needs custom ingestion and storage logic
RapidDev builds these features for production
Real auth, database, and payments — fixed price, delivered in weeks. You own 100% of the code.
Frequently asked questions
Which weather API is most accurate for a small web app?
For most apps, Open-Meteo and OpenWeatherMap produce comparable accuracy for standard current conditions and 7-day forecasts. Open-Meteo is free with no API key and pulls from multiple global models (GFS, ECMWF, DWD), making it the best starting point. If you need minute-level precipitation, air quality, or pollen count, Tomorrow.io has the richer data but starts at $150/mo.
Do I need an API key to use weather data in my app?
Not always. Open-Meteo is completely free for commercial use with no API key required — just make a GET request to their public endpoint. OpenWeatherMap and Tomorrow.io require a key even on their free tiers. If you use a key, it must live in a server-side environment variable and be called through an API route or Edge Function, never in frontend code.
How do I avoid exposing my weather API key in the browser?
Create a Next.js API route (app/api/weather/route.ts) or a Supabase Edge Function that receives lat/long from your React component, adds the key from a server environment variable, calls the weather API, and returns the data. The browser only ever sees your own domain in the Network tab — the real API key is never sent to the client. After deploying, open DevTools Network and confirm no calls go directly to api.openweathermap.org.
How often should I refresh the weather data to balance accuracy and API costs?
A 15-minute cache is the right default for most apps — weather models only update every 1–6 hours anyway, so more frequent fetching wastes API calls without improving accuracy. Set Cache-Control: s-maxage=900, stale-while-revalidate=1800 on your API route response. For real-time rain radar or minute-precision data, you'd need a paid weather API and a shorter 1–5 minute cache.
Can I show weather for multiple locations on the same page?
Yes, but each location needs its own API call. If you display 5 cities simultaneously, that's 5 calls per page load — multiply by your daily active users and you'll exhaust a free tier quickly. Pre-cache weather for your fixed location set (e.g., your top 10 cities) on a schedule using Vercel Cron or Supabase pg_cron, and serve those cached results to all users.
How do I handle the case where the user denies location permission?
Always include a city name search input as a fallback. When navigator.geolocation.getCurrentPosition() returns a PermissionDeniedError, show the search input automatically with a short message like 'Location access denied — search for a city instead.' Use the OpenWeatherMap Geocoding API or Mapbox Geocoding API to convert the city name to lat/long before calling your weather proxy.
What's the difference between OpenWeatherMap, Open-Meteo, and Tomorrow.io?
Open-Meteo is free, open-source, and no-key — best for budget-conscious projects. OpenWeatherMap is the most documented option with a 1,000 call/day free tier and paid tiers from $40/mo — best when you need reliable official docs and a large community. Tomorrow.io has the richest data (air quality, pollen, UV, minute precipitation) and starts at $150/mo — best for vertical apps where weather accuracy directly affects user decisions.
Can I add weather-based alerts that notify users by email or push notification?
Yes, but this requires more infrastructure than a display widget. You need to store user locations in a database, run a scheduled job (Vercel Cron, Supabase pg_cron) that fetches forecast data and compares it against user-defined thresholds, and a notification delivery service (Resend for email, web push for browser notifications). This is typically where a basic AI-built widget becomes a custom development project.
Need this feature production-ready?
RapidDev builds a weather forecast integration into real apps — auth, database, payments — at $13K–$25K.
Book a free consultation30-min call. No commitment.