# Ag Weather-Yield Risk Reference Data (`conceivable_extension/ag-weather-yield-risk-data`) Actor

Real NOAA daily weather station data and USDA county crop-yield history, plus standard derived indices (GDD, rainfall deficit) — a public-data reference layer, not yield prediction or satellite-based underwriting scoring.

- **URL**: https://apify.com/conceivable\_extension/ag-weather-yield-risk-data.md
- **Developed by:** [joseph fadero](https://apify.com/conceivable_extension) (community)
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $4.00 / 1,000 weather snapshot returneds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Ag Weather-Yield Risk Reference Data

**A public-data reference layer — not yield prediction, not satellite imagery, not underwriting-grade risk scoring.** The parametric insurance market (agriculture-driven) is projected to reach $29.3B by 2029, with a documented uninsured-loss gap ($9.4B of 2024 US crop/rangeland losses were uninsured). The PRD for this actor was explicit that this is the lowest-confidence idea in the whole build program, and that real commercial value in this space (satellite imagery, ML yield prediction) is beyond scraping scope — this is deliberately scoped to real weather-station data, real historical yield statistics, and the standard, well-documented derived indices computed from them.

### Phase 1 — the go/no-go decision, and what it actually found

The PRD required a go/no-go decision before any further build: shelve this actor rather than force a weak version if clean, free sources couldn't be confirmed for even one well-documented market. Both real sources needed for the US market were confirmed live:

| Source | Verdict | What was actually found |
|---|---|---|
| **NOAA GHCN-Daily** (weather) | ✅ Go | Real, free, **keyless** per-station daily CSV files — no signup, no token, no rate limit hit. Confirmed live: 80 years of daily data for a major agricultural station (Des Moines, IA), current through essentially today. Genuine US federal public-domain data. |
| **USDA NASS Quick Stats** (yield) | ✅ Go, via a different path than expected | The documented query API (`quickstats.nass.usda.gov`) needs a free but email-delivered key — and that domain was unreachable entirely during this build's research (a real connectivity issue, not necessarily permanent, but not depended on). The real fix: NASS also publishes a **fresh, complete, keyless bulk data file every single day** — confirmed live, 23.8 million real rows, every crop/county/year back to the 1920s in places. Used instead of the API, avoiding any key/signup requirement for this actor at all. |

**A source seriously considered and ruled out:** Open-Meteo's historical weather API is genuinely keyless and returns real, clean data — but its free tier's terms of use explicitly restrict it to non-commercial use, and this actor is a commercial product. NOAA's own data has no such restriction (genuine public domain), so it was used instead — a real terms-of-use check, not an oversight.

### The real tradeoff: no API keys needed, but yield\_history is slow

Avoiding NASS's key-signup friction means every `yield_history` call streams and filters a **fresh ~1.1GB government file server-side** (never held fully in memory — piped through gunzip and read line-by-line). Confirmed live this takes **roughly 1-4 minutes** depending on network conditions. Results are cached in a named key-value store per day+state+county+commodity, so repeat queries against the same day's file are fast (confirmed live: 66 seconds cold, 1.3 seconds cached, same correct 160-record result both times). `weather_snapshot` and `index_calculation` modes are fast (a few seconds) — this cost is specific to `yield_history`.

### Coverage: 5 real, individually-verified counties — not global geocoding

Per the PRD's own recommended v1 scope ("at least one well-documented market"), this covers 5 major US agricultural counties across the corn/soybean/wheat belt, each with an independently-verified NOAA station AND confirmed-matching USDA state/county name strings:

| Region key | County | NOAA station | Primary crops |
|---|---|---|---|
| `story_county_ia` | Story County, IA | Des Moines Intl Airport | Corn, soybeans |
| `champaign_county_il` | Champaign County, IL | Champaign/Urbana Willard | Corn, soybeans |
| `sangamon_county_il` | Sangamon County, IL | Springfield | Corn, soybeans |
| `lancaster_county_ne` | Lancaster County, NE | Lincoln Airport | Corn, soybeans |
| `sedgwick_county_ks` | Sedgwick County, KS | Wichita | Winter wheat |

Not exhaustive geocoding — adding a county means adding one verified station+county-name pair to `src/data/regions.ts`, the same pattern used for these 5, not a structural rebuild.

### Modes

| Mode | Behavior |
|---|---|
| `weather_snapshot` | Real NOAA daily precipitation/TMAX/TMIN for a date range — one record per day per metric |
| `yield_history` | Real USDA county-level annual yield for a crop, every year on record, both GRAIN and SILAGE practices where NASS reports both separately |
| `index_calculation` | A derived index computed from real weather data: `growing_degree_days` (base 10°C, the standard corn/soybean convention), `cumulative_precipitation`, or `rainfall_deficit` (actual vs. the same station's own 10-year historical average for the same calendar period — a real, defensible baseline computed from data already being fetched, not a separate unverified "normals" product) |

All three index formulas were verified against manually-computed test cases before shipping (e.g. a single day's GDD hand-calculated from its own TMAX/TMIN and compared to the function's output).

### Output schema

```json
{
  "region": "string",
  "cropType": "string | null",
  "dataType": "weather | yield_history | derived_index",
  "value": "number | null",
  "unit": "string",
  "periodStart": "string",
  "periodEnd": "string",
  "historicalPercentile": "number | null",
  "sourceUrl": "string",
  "checkedAt": "ISO timestamp",
  "status": "success | failed",
  "errorMessage": "string | null"
}
```

`historicalPercentile` is populated for `yield_history` (a year's rank among all years on record for that county/crop/practice) and `null` elsewhere — not computed for weather data, where a single day's rank against decades of daily values would be a different, unverified calculation this build didn't attempt.

### What this is not

Not yield prediction. Not satellite-based analysis. Not an underwriting-grade risk score. Every figure here is either raw government data or a standard, named, documented formula (GDD base-10°C accumulation; deficit vs. own-station historical average) — never a proprietary model. If you need actual yield forecasting, the PRD's own research points to Agrograph, EarthDaily, and Munich Re as the real competitors in that different, harder problem.

### Pricing

| Event | Price |
|---|---|
| Run started | £0.05 |
| Reading success | £0.06 |
| Fetch failed | free |

### Setup note

No browser needed — both real sources (NOAA, USDA NASS) work over plain HTTP. `yield_history` mode needs a generous timeout (this actor defaults to 600s) to comfortably cover the real, uncached ~1-4 minute bulk-file streaming cost.

### n8n integration

- **Workflow A (trigger):** scheduled run pulling current-season weather/index data for a tracked set of regions.
- **Workflow B (processing):** report current-season index values against `historicalPercentile` context — useful signal for ag-fintech buyers layering their own risk models on top of this reference data, not a replacement for one.

# Actor input Schema

## `mode` (type: `string`):

weather\_snapshot: real NOAA daily station data for a date range. yield\_history: real USDA county-level historical crop yield (note: this mode streams a fresh ~1GB government file server-side and typically takes 2-4 minutes — see README). index\_calculation: derived index (GDD, rainfall deficit, cumulative precipitation) computed from real weather data.

## `region` (type: `string`):

One of 5 curated, verified US agricultural counties: story\_county\_ia, champaign\_county\_il, sangamon\_county\_il, lancaster\_county\_ne, sedgwick\_county\_ks — see README for what each covers and why only these 5 in v1.

## `cropType` (type: `string`):

Required for yield\_history mode. Real USDA commodity name, e.g. "CORN", "SOYBEANS", "WHEAT".

## `dateRange` (type: `object`):

{ "from": "YYYY-MM-DD", "to": "YYYY-MM-DD" } for weather\_snapshot/index\_calculation. For yield\_history, only the year portion of "from"/"to" is used (crop yield is an annual figure, not daily).

## `indexType` (type: `string`):

Required for index\_calculation mode.

## Actor input object example

```json
{
  "mode": "weather_snapshot",
  "region": "story_county_ia",
  "cropType": "CORN",
  "dateRange": {
    "from": "2026-05-01",
    "to": "2026-08-01"
  },
  "indexType": "growing_degree_days"
}
```

# Actor output Schema

## `resultsDatasetUrl` (type: `string`):

Dataset of weather/yield/derived-index records produced by this run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "dateRange": {
        "from": "2026-05-01",
        "to": "2026-08-01"
    }
};

// Run the Actor and wait for it to finish
const run = await client.actor("conceivable_extension/ag-weather-yield-risk-data").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "dateRange": {
        "from": "2026-05-01",
        "to": "2026-08-01",
    } }

# Run the Actor and wait for it to finish
run = client.actor("conceivable_extension/ag-weather-yield-risk-data").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "dateRange": {
    "from": "2026-05-01",
    "to": "2026-08-01"
  }
}' |
apify call conceivable_extension/ag-weather-yield-risk-data --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,conceivable_extension/ag-weather-yield-risk-data"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/Zl1dy5BRlLyAky8GK/builds/CNbxpYNyikTI05UGd/openapi.json