Agriculture & Environment
Crop Yield Forecasting API
Everyone in the chain is making decisions against a number nobody has: how much will actually come off this ground. The useful product is that number with its error bars attached.
- Agritech platforms
- Crop insurers
- Agricultural lenders
- Grain traders and buyers
- Input suppliers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Yield forecasting sits under a surprising number of commercial decisions. A grain buyer forwards-sells against expected supply. A lender sizes an operating loan against expected revenue. An insurer prices and reserves against expected shortfall. A cooperative schedules drying and storage capacity. All of them currently work from a mix of government estimates, agronomist judgement and last year's number.
The modelling is genuinely tractable at regional scale. Satellite vegetation indices track canopy development, weather drives water and heat stress, soil sets the moisture-holding capacity, and the relationship between those and final yield is strong enough across a region to be useful by mid-season. Regional estimates can get good well before harvest.
Field level is a much harder problem and it is important to be straight about why. A regional estimate benefits from averaging across hundreds of fields, so individual idiosyncrasies cancel out. A single field has no such averaging: its yield depends on the specific variety planted, the exact sowing date, the fertiliser actually applied, drainage that only the farmer knows about, a hail cell that hit one corner, and a harvest loss that depends on the combine operator. Satellite and weather data cannot see most of that. Field-level forecasts are therefore both less accurate and more variable in accuracy, and anyone selling them as equivalent to regional estimates is misrepresenting the product.
Who buys this
Agritech platforms, Crop insurers, Agricultural lenders, Grain traders and buyers, Input suppliers
What the API returns
What comes back
- Expected yield per field, farm or administrative region with prediction intervals
- Within-season forecast updates as the crop develops
- Deviation from the location's own historical yield distribution
- Stress attribution identifying which factor is limiting yield
- Phenology estimates — growth stage and expected harvest window
- Regional aggregation for supply and production estimates
- Confidence flags where input data is sparse, cloudy or unverified
- Measured forecast accuracy by crop, region and lead time
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/yield/forecast | Yield forecast for fields, farms or regions |
| GET | /v1/fields/{id}/forecast | Current forecast and revision history for one field |
| GET | /v1/regions/{region}/production | Aggregated production estimate for a region |
| GET | /v1/fields/{id}/stress | Stress attribution over the season to date |
| GET | /v1/fields/{id}/phenology | Estimated growth stage and harvest window |
| GET | /v1/accuracy | Measured accuracy by crop, region and lead time |
Request and response
illustrativeRequest
{
"fields": [
{ "field_id": "f_22181", "crop": "winter_wheat", "geometry_ref": "geo_22181",
"sown_on": "2025-10-08", "variety": "KWS Extase" }
],
"region_rollup": "GB-LIN",
"season": "2026",
"include": ["intervals", "stress", "phenology"]
}Response
{
"season": "2026",
"issued_at": "2026-06-18T00:00:00Z",
"fields": [
{
"field_id": "f_22181",
"crop": "winter_wheat",
"area_ha": 41.2,
"forecast_t_per_ha": { "p50": 8.42, "p10": 7.11, "p90": 9.55 },
"vs_field_history": { "field_5y_mean": 8.90, "percentile": 0.38 },
"phenology": { "stage": "grain_fill", "expected_harvest": "2026-08-06",
"harvest_window_days": 9 },
"stress": [
{ "factor": "water_deficit", "severity": "moderate",
"period": "2026-05-18/2026-06-04", "estimated_yield_effect_t_ha": -0.46 },
{ "factor": "heat_at_anthesis", "severity": "low",
"period": "2026-06-07/2026-06-09", "estimated_yield_effect_t_ha": -0.12 }
],
"confidence": { "band": "medium",
"limits": ["7 of 12 recent satellite passes obscured by cloud",
"variety and input records self-reported"] }
}
],
"region": { "code": "GB-LIN", "crop": "winter_wheat",
"production_estimate_kt": 1182.4, "interval_kt": [1061.0, 1298.6] }
}Where the data comes from
| Satellite optical imagery | Sentinel-2 and Landsat for vegetation indices — open data with attribution requirements, which makes the core of this buildable without a licence negotiation |
| Satellite radar imagery | Sentinel-1, also open, used where cloud cover prevents optical observation and for structural crop signals |
| Weather observations and reanalysis | Temperature, rainfall, radiation and evapotranspiration. National networks and open reanalysis such as ERA5 are usable commercially; some national met archives are licensed |
| Soil property data | Open global and national soil datasets for water-holding capacity and texture. Resolution is coarse relative to field variation, which is a real limit on field-level accuracy |
| Official yield statistics | Government and statistical agency yield series by region — the training label for regional models and the only large-sample ground truth available |
| Grower-reported records | Variety, sowing date, inputs and harvested yield where the platform collects it. Transforms field-level accuracy, and comes with consent and ownership questions that have to be settled before a model trains on it |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Regional and field-level models built and validated separately, with their own accuracy reporting, rather than one model served at two resolutions
- Vegetation index time series fitted as a seasonal curve per field, with curve shape features — peak greenness, integral, senescence rate — doing more predictive work than any single observation
- Radar backscatter substituted during extended cloud, with the resulting confidence reduction stated in the response rather than silently absorbed
- Water balance modelling from rainfall, evapotranspiration and soil water-holding capacity, since cumulative deficit predicts yield better than rainfall totals
- Phenology estimated from thermal time and observed canopy development, because growth-stage timing determines which weather events matter
- Stress attribution computed as counterfactual effect — what the model predicts with and without the observed stress period — and reported as an estimate
- Walk-forward validation by season and lead time, reported separately for field and regional output, with accuracy by lead time published so a June forecast is not confused with an August one
- Monitoring for sensor changes, satellite constellation gaps and drift in reported ground truth, all of which degrade a yield model quietly
What it changes for the business
Supply visibility
Regional production estimates weeks before official figures change forward-selling and logistics planning.
Credit decisions
Expected revenue with stated uncertainty gives a lender something better than last year's yield.
Insurance reserving
Within-season shortfall estimates allow reserving and loss adjustment planning before claims arrive.
Agronomic targeting
Stress attribution directs scarce agronomist attention to the fields where it will change the outcome.
How it fits into your product
How it embeds
- Field geometry accepted as GeoJSON, or referenced from boundaries you already hold
- Within-season refresh on a schedule, with revision history so a changed forecast is auditable
- Regional rollups for trading and planning teams alongside field detail for agronomy
- Webhooks on material forecast revisions and new stress events
- White-label delivery for agritech platforms serving growers under their own brand
- Deployment inside your environment where grower data cannot leave your systems
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How accurate is field-level yield forecasting?
Materially less accurate than regional, and the gap is structural rather than a modelling shortfall. Regional estimates average out field-specific factors; a single field has no averaging, and much of what drives its yield — actual fertiliser applied, drainage, a localised hail event, harvest losses — is invisible to satellite and weather data. Mid-season field forecasts commonly carry errors in the range of ten to twenty percent against final yield, and wider where grower records are absent. We publish measured accuracy by lead time so the number is visible rather than implied.
When in the season does the forecast become useful?
It improves steadily. Before emergence it is essentially climatology plus soil and historical yield. By the time the canopy has developed it carries real information, and through grain fill it tightens considerably. A forecast at sowing and a forecast three weeks before harvest are different products, and we would return lead time and accuracy with every response rather than presenting them on the same footing.
Can you do this without grower-reported data?
Yes, and many deployments have to. Open satellite, weather and soil data support the whole pipeline. Grower records on variety, sowing date and inputs improve field-level accuracy noticeably, and if your platform collects them the model should use them — subject to settling consent and data ownership with the growers first, which is a contractual matter and not something we would work around.
Can we resell the satellite data itself?
The derived indices and forecasts are yours. Sentinel and Landsat are open but carry attribution requirements that have to appear somewhere in your product, and some higher-resolution commercial imagery is licensed per-seat or per-hectare with explicit redistribution bans. If your product needs to display imagery rather than derived values, that is a licensing decision we would resolve during discovery rather than after the build.
What about crops with no official yield statistics?
They are harder, because the training label is missing. For specialty and minor crops we would either rely on grower-reported harvest data, which usually means a smaller and noisier sample, or decline. A model fitted on a few dozen observations will produce confident-looking numbers with no real validation behind them, and we would rather say that at the start.
Related blueprints
Satellite Crop Monitoring API
Vegetation indices, crop stress detection and field change monitoring from satellite imagery, as a data layer for agritech and insurance software.
Crop Disease Risk API
Weather-driven disease and pest risk scoring with outbreak alerts and scouting recommendations, for agronomy and input platforms.
Soil Suitability Scoring API
Soil properties, crop suitability scores and land productivity estimates for land valuation, lending and agronomic planning.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.