Dark Sky API Replacement — The Drop-In Weather Wrapper Your Legacy Code Has Been Waiting For

Your Dark Sky integration broke on March 31, 2023. This actor makes it work again — same JSON shape, same field names, no rewrite required.

On March 31, 2023, Apple flipped the switch and the Dark Sky API — the one that powered half the weather apps, commute notifiers, agritech dashboards, irrigation controllers, and smart-home routines on the internet — simply stopped answering. No grace period, no drop-in successor, no "use this URL instead" migration guide. Apple rolled Dark Sky's tech into WeatherKit, a paid, Apple-ID-gated iOS/macOS SDK that is useless to anyone running a Python cron job, a Home Assistant blueprint, a Node.js Slack bot, an n8n workflow, a Rails backend, a Flutter app on non-Apple platforms, or basically any non-Xcode codebase on the planet.

Thousands of indie apps, academic research pipelines, and production integrations were left with two options: ship a full rewrite against OpenWeatherMap / Tomorrow.io / Visual Crossing (each with a different response shape, a different auth model, and a different paid tier wall), or let the feature die.

This actor is the third option. It wraps the excellent, genuinely-free, academically-backed Open-Meteo API and reshapes the response to match Dark Sky's exact JSON schema — currently, hourly.data[], daily.data[], icon, summary, temperature, apparentTemperature, dewPoint, humidity, pressure, windSpeed, windBearing, cloudCover, uvIndex, visibility, all of it. Point your existing Dark Sky client at this actor's dataset instead of api.darksky.net and most integrations keep working with zero code changes beyond the base URL.

Zero auth. No API keys. No monthly minimum. You pay $0.002 per forecast event via Apify's pay-per-event billing; the underlying weather data itself is free.

---

Why Open-Meteo Is the Right Backend

Open-Meteo is a German-run, academically-supported weather API that aggregates data from the national forecasting services (DWD, NOAA/NWS, Météo-France, ECMWF, JMA, CMC, MeteoSwiss, etc.) and serves it through a clean, CORS-friendly HTTP endpoint. Relevant points:

• Free for non-commercial use out of the box, no API key. Commercial tiers exist but most small-to-mid workloads fit under the free ceiling.
• High-resolution global coverage. Runs the same numerical models the national services run — the data quality is excellent.
• Variables match Dark Sky's field set almost 1:1. Temperature, apparent temperature, dew point, relative humidity, surface pressure, wind (speed + bearing), cloud cover, UV index, visibility, precipitation amount, precipitation probability, weather code — every one of these has a direct Dark Sky counterpart.
• Unit systems are selectable on the request. Fahrenheit/mph/inches (Dark Sky US default), Celsius/m-s/mm (SI), Celsius/km-h/mm (CA), Celsius/mph/mm (UK2) — all handled server-side, so your reshaped Dark Sky flags.units value stays honest.
• Reasonable terms. Open-source, documented methodology, no predatory enterprise funnel.

Open-Meteo is what Dark Sky would look like if it were reborn in 2023 as a public-good project instead of being absorbed into an Apple platform SDK. This actor's only job is to paper over the shape difference so your existing code doesn't care.

---

Side-by-Side Schema Mapping

Here's how every Dark Sky field maps back to Open-Meteo — and where we had to fill gaps or soften the promise.

Dark Sky field	Open-Meteo field	Notes
latitude	latitude	Identical.
longitude	longitude	Identical.
timezone	timezone	Identical (IANA tz name, e.g. America/Los_Angeles).
offset	utc_offset_seconds / 3600	Converted to hours to match Dark Sky.
currently.time	current.time	ISO-8601 converted to Unix epoch seconds.
currently.summary	derived from weather_code	We map WMO codes to Dark Sky-style short text ("Partly Cloudy", "Light Rain", etc.).
currently.icon	derived from weather_code + is_day	WMO code → Dark Sky icon slug (clear-day, partly-cloudy-night, rain, snow, sleet, fog, cloudy, thunderstorm).
currently.temperature	temperature_2m	Units follow the selected preset.
currently.apparentTemperature	apparent_temperature	Direct.
currently.dewPoint	dew_point_2m	Direct.
currently.humidity	relative_humidity_2m / 100	Open-Meteo returns 0–100, Dark Sky returned 0.0–1.0. We scale.
currently.pressure	surface_pressure	hPa.
currently.windSpeed	wind_speed_10m	Units follow preset.
currently.windBearing	wind_direction_10m	Degrees, 0–359.
currently.cloudCover	cloud_cover / 100	Scaled 0.0–1.0 to match Dark Sky.
currently.uvIndex	uv_index	Direct.
currently.visibility	visibility	Meters in SI units, miles in US preset.
currently.precipIntensity	precipitation	Units follow preset.
currently.precipProbability	precipitation_probability / 100	Scaled to 0.0–1.0.
hourly.data[]	hourly.* arrays	Zipped index-by-index into Dark Sky's "array of objects" shape.
daily.data[]	daily.* arrays	Same — includes sunriseTime / sunsetTime converted to epoch.
alerts[]	(no equivalent)	Open-Meteo does not publish unified severe-weather alerts. We return [] when requested and add a flags.alerts_note explainer. See Limitations.
flags.units	—	Echoed from your input.
flags.sources	—	Set to ["open-meteo"].

Fields like nearestStormDistance, ozone, and moonPhase that Dark Sky exposed but Open-Meteo doesn't mirror by default are simply omitted rather than returned as fake zeros. If your code .get()s them with a default, nothing changes.

---

Drop-In Migration Example

Before (Dark Sky, dead since March 2023):

GET https://api.darksky.net/forecast/YOUR_API_KEY/37.7749,-122.4194?units=us

After (this actor, synchronous mode):

curl -X POST \
  "https://api.apify.com/v2/acts/nexgendata~dark-sky-replacement/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "coordinates": ["37.7749,-122.4194"],
    "units": "us",
    "days": 7
  }'

The response body is a JSON array of one forecast object, where that object has the exact same latitude / longitude / timezone / currently / hourly.data / daily.data shape Dark Sky used to return. If your code did:

forecast = requests.get(darksky_url).json()
temp = forecast["currently"]["temperature"]
for hour in forecast["hourly"]["data"]:
    ...

…change it to:

forecasts = requests.post(apify_url, json={"coordinates": ["37.7749,-122.4194"]}).json()
forecast = forecasts[0]
temp = forecast["currently"]["temperature"]
for hour in forecast["hourly"]["data"]:
    ...

That's the entire migration in most codebases. Extract-one-line-swap-one-line.

---

Python Example with ApifyClient

For production use — especially bulk lookups across many cities — use the official Apify client:

from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

run = client.actor("nexgendata/dark-sky-replacement").call(run_input={
    "coordinates": [
        "37.7749,-122.4194",   # San Francisco
        "40.7128,-74.0060",    # New York
        "51.5074,-0.1278",     # London
        "35.6762,139.6503",    # Tokyo
    ],
    "units": "us",
    "include_hourly": True,
    "include_daily": True,
    "include_alerts": False,
    "days": 7,
})

for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item["timezone"], "->", item["currently"]["temperature"], "°F")
    print("  tomorrow high:", item["daily"]["data"][1]["temperatureHigh"])

One forecast event fires per coordinate, so the run above costs 4 × $0.002 = $0.008.

---

5 Real Use Cases

1. Resurrecting a Legacy Dark Sky Python / Node Service

You have a production cron job written in 2019 that pulls the Dark Sky forecast, posts tomorrow's high to Slack at 8am, and has been broken for over two years. Swap the base URL to this actor, leave every other line alone, and it works again. Takes fifteen minutes, not a sprint.

2. Home Assistant / Smart-Home Automations

Dozens of community Home Assistant blueprints and Node-RED flows hard-coded the Dark Sky JSON shape — irrigation controllers, EV charging schedules, window-blind automations. This actor gives them a backend again without rewriting every blueprint to match OpenWeatherMap's wildly-different shape.

3. Indie Weather App with Paying Users

You ship a small iOS/Android/web weather app, you built it against Dark Sky five years ago, and you absolutely do not want to re-architect around Apple's WeatherKit (which is iOS-only, Apple-ID-gated, and legally sketchy to proxy to non-Apple platforms). Point your backend at this actor instead.

4. Agritech / Irrigation Scheduling

Farmers running Dark Sky-based evapotranspiration models for irrigation timing were hit hard when it went dark. Open-Meteo delivers the same temperature_2m + dew_point_2m + wind_speed_10m + precipitation set that ET formulas need, in the Dark Sky field names the existing calculation modules expect.

5. Academic / Climate-Research Pipelines

Research codebases that processed thousands of lat/lng points against Dark Sky's hourly API for historical retrospectives. Open-Meteo exposes both forecast and (separately) reanalysis endpoints; this actor fronts the forecast side today, and you can plug the same reshape logic into a historical variant when needed.

---

Dark Sky vs This Actor vs The Paid Alternatives

Capability	Dark Sky (2016–2023)	This actor (Open-Meteo)	OpenWeatherMap One Call	Tomorrow.io	Apple WeatherKit
Status in 2026	Dead since March 2023	Active	Active	Active	Active
JSON shape	Dark Sky proprietary	Dark Sky-compatible	OWM proprietary	Tomorrow.io proprietary	Apple proprietary
Auth required	API key	No auth (via Apify token)	API key	API key	Apple ID + JWT + team key
Free tier	1,000 calls/day	Pay-per-event, no cap	1,000 calls/day	500 calls/day	500k calls/month (rate-limited)
Price per 1,000 forecasts	~$0 (free tier) then $0.0001	~$2 via PPE	~$18 on paid tier	~$10 on paid tier	Free within Apple quota, else $0.50–$2.50
Works from non-Apple platforms	Yes	Yes	Yes	Yes	No — Apple ecosystem only
Severe weather alerts	Yes	Stub (empty array + note)	Yes	Yes	Yes
Global coverage	Yes	Yes	Yes	Yes	Yes
Academic / open methodology	No	Yes (Open-Meteo is open-source)	No	No	No
Rate limit headaches	Yes	None — Apify handles retries	Yes	Yes	Yes

For severe-weather alerting you still want NWS / Meteoalarm / BOM directly. For everything else — current conditions, hourly, daily forecast — this is the simplest and cheapest way to get back to a working Dark Sky-shaped response today.

---

Why Run This on NexGenData / Apify?

• Zero infra. No HTTP client retry loop, no WMO-code mapping table, no epoch conversion, no unit scaling. Paste coordinates, click Run.
• Batch-friendly. Up to thousands of lat,lng strings per run — one PPE event per coordinate.
• Pay-per-event pricing. No monthly seat. A 7-day forecast for one city is $0.002. A 500-city workload is $1.00.
• Clean data contract. Stable Dark Sky-shaped JSON, graceful nulls for missing fields, ISO-8601 → epoch conversion done for you.
• Integrations. Pipe output to Google Sheets, Slack, Zapier, Make, n8n, or your own webhook via standard Apify integrations.
• Survives backend changes. If Open-Meteo changes its shape or we add a secondary provider, the actor's output contract stays Dark Sky-shaped.

---

Related Actors in the NexGenData Suite

• heroku-cost-calculator — Estimate your Heroku bill and compare migration costs to Railway, Render, Fly.io, Cloudflare Workers, and DigitalOcean.
• tranco-rank-lookup — Free Alexa Rank alternative using academic Tranco data.
• company-data-aggregator — Bulk company profile from WHOIS, DNS, GitHub, SSL, tech stack. Great for enriching location-based customer data.
• iex-replacement — Same "killed API, rebuilt cheap" playbook for IEX Cloud's discontinued financial endpoints.

---

FAQ

Q: Is the output really identical to Dark Sky's response? Field names and shape: yes, intentionally. The top-level keys (latitude, longitude, timezone, offset, currently, hourly.data[], daily.data[], flags) and their inner keys match Dark Sky's schema. A few fields Dark Sky exposed (e.g. ozone, nearestStormDistance, moonPhase) are simply omitted because Open-Meteo doesn't publish them — if your code .get()s those with defaults, you won't notice. Numeric values are returned in the same unit system Dark Sky used for the requested preset.

Q: Why didn't Apple just keep Dark Sky running? Apple bought Dark Sky in 2020, integrated the tech into iOS weather and then into WeatherKit, and killed the public API because (a) running a free public weather endpoint has a real infrastructure cost, and (b) WeatherKit monetizes the same tech via Apple Developer Program seats. Commercially rational, developer-hostile — which is why the public had to build its own replacement.

Q: Is Open-Meteo going to disappear too? Open-Meteo is open-source (see their GitHub) and the server software itself can be self-hosted against freely-available weather model outputs from DWD, NOAA, ECMWF, etc. Even if the hosted endpoint went away tomorrow, anyone could spin up a compatible instance. That's a meaningfully different risk profile from "Apple's SDK team decides to deprecate it."

Q: What about severe-weather alerts? Open-Meteo doesn't publish a unified alerts feed. When you enable include_alerts, this actor returns an empty alerts: [] array plus a flags.alerts_note explainer — enough to keep existing Dark Sky clients that iterate the array from crashing, without pretending to deliver data we don't have. For production alerting, subscribe directly to the National Weather Service (CAP feed), Meteoalarm (Europe), BOM (Australia), or Environment Canada's feeds.

Q: Does this work for historical weather (dates in the past)? Not at the moment. Open-Meteo has a separate /archive endpoint backed by the ERA5 reanalysis dataset. If there's demand we'll publish a dark-sky-historical-replacement sibling actor wired to that endpoint with the same reshape logic.

Q: Is the data accurate enough for production? Yes, with a caveat. Open-Meteo serves the same operational model outputs the national weather services serve — it's not a second-class panel estimate. Forecast accuracy is comparable to Dark Sky in its prime. Current-conditions "temperature" is model-interpolated rather than read from the nearest physical station (Dark Sky did the same thing), so in extreme microclimates you may see 1–2°F drift versus a specific airport METAR. For irrigation, routing, commute notifications, home-automation triggers, and general consumer weather apps, it's excellent.

Q: Can I use this commercially? Open-Meteo is free for non-commercial use and offers paid tiers for commercial deployments. Small-to-mid commercial workloads generally fit under the hosted free ceiling, but if you're making thousands of calls per minute you should review Open-Meteo's terms and consider their commercial plan or self-hosting. The Apify-side billing ($0.002/forecast) is independent of Open-Meteo's terms.

Q: What's the rate limit? There's no hard rate limit inside this actor — Open-Meteo's public endpoint is generous, and Apify handles the concurrency. For runs of 10,000+ coordinates, split into multiple actor runs rather than one giant batch to keep run-duration manageable.

---

Built by NexGenData — more "killed API, reborn cheaper" actors at apify.com/nexgendata