Home/Offers/Agriculture & Environment/Crop Disease Risk API

Agriculture & Environment

Crop Disease Risk API

Most fungal disease decisions come down to whether the last ten days of weather suited the pathogen. That is computable, and it is still usually guessed.

Agritech and agronomy platforms
Input retailers and distributors
Cooperatives
Crop insurers
Large growing operations

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Fungal crop disease has an unusual property for an agricultural problem: it is strongly determined by weather in ways that have been studied for decades. Septoria needs rain splash and a temperature window. Potato late blight needs humidity above a threshold for a sustained period. Many pathogens have published infection models with specific hour-by-hour conditions, derived from controlled experiments and validated in the field.

Yet the operational decision is usually made on habit and calendar. A grower sprays at growth stage 32 because that is when they always spray, which means spending money in a dry season when the pathogen never had conditions to establish, and missing the application in a wet one when it did. The economic cost runs both ways, and in regions with fungicide resistance management requirements an unnecessary application also carries a regulatory cost.

The data needed is mostly available. Hourly weather at field resolution, soil moisture, crop growth stage and a pathogen model are enough to produce an infection risk that is genuinely more informative than the calendar. Where it gets harder is inoculum pressure — whether the pathogen is actually present in the area — which depends on regional disease surveillance that varies enormously in quality between countries and crops.

Who buys this

Agritech and agronomy platforms, Input retailers and distributors, Cooperatives, Crop insurers, Large growing operations

Category: Agriculture & Environment

What the API returns

What comes back

Infection risk scores per field, crop and pathogen
Accumulated infection pressure over the season to date
Threshold breach alerts with the conditions that triggered them
Scouting recommendations prioritised by field and risk
Spray window suggestions based on risk and weather suitability
Regional outbreak signals where surveillance data exists
Growth stage context, since susceptibility varies by stage
Model provenance — which published infection model produced each score

Endpoints

Method	Path	Returns
POST	/v1/risk/disease	Disease risk scores for fields and pathogens
GET	/v1/fields/{id}/risk	Current and accumulated risk for one field
GET	/v1/fields/{id}/scouting	Prioritised scouting recommendations
GET	/v1/regions/{region}/outbreaks	Regional outbreak signals and surveillance reports
GET	/v1/pathogens	Supported pathogens, crops and the models behind them
WS	/v1/stream	Push threshold breaches and new outbreak signals

Request and response

illustrative

Request

{
  "fields": ["f_22181", "f_22196"],
  "crop": "winter_wheat",
  "pathogens": ["septoria_tritici", "yellow_rust", "fusarium_head_blight"],
  "lookback_days": 21,
  "forecast_days": 7
}

Response

{
  "issued_at": "2026-05-22T06:00:00Z",
  "fields": [
    {
      "field_id": "f_22181",
      "growth_stage": "GS39",
      "risks": [
        {
          "pathogen": "septoria_tritici",
          "risk_score": 78,
          "band": "high",
          "model": "rain_splash_infection_period_v3",
          "infection_periods_21d": 4,
          "last_period": { "from": "2026-05-19T14:00:00Z", "to": "2026-05-20T09:00:00Z",
                           "rainfall_mm": 11.4, "wet_hours": 19 },
          "forecast_risk_7d": "high",
          "susceptibility_at_stage": "high"
        },
        {
          "pathogen": "yellow_rust",
          "risk_score": 31,
          "band": "low",
          "model": "temperature_humidity_v2",
          "note": "Temperatures below optimal for sporulation through the window"
        }
      ],
      "scouting": {
        "priority": 1,
        "recommendation": "Inspect lower canopy leaves 3 and 4 within 3 days",
        "rationale": "Four infection periods since GS32 with high stage susceptibility"
      },
      "inoculum_context": { "regional_surveillance": "reported_present",
                            "source_confidence": "medium", "as_of": "2026-05-15" }
    }
  ]
}

Where the data comes from

Hourly weather at field resolution	Temperature, relative humidity, rainfall, leaf wetness and wind, from gridded analysis blended with any on-farm stations. Open reanalysis and national networks cover most of this; some high-resolution products are licensed
Published pathogen infection models	Decades of peer-reviewed epidemiological work giving the specific conditions each pathogen needs. Implementing published models with citation is the honest basis for this product
Regional disease surveillance	Official and cooperative monitoring reports on pathogen presence. Quality varies hugely by country and crop, and some sources prohibit commercial redistribution
Crop growth stage data	From grower input, satellite phenology or thermal time models, since susceptibility is stage-dependent
Field geometry and soil data	Microclimate differs across a farm, and soil moisture affects canopy humidity
Grower-reported observations	Scouting results and confirmed infections, which are the only way to validate the model locally — and require consent to use

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

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.

Published infection models implemented as specified and cited, rather than replaced by an opaque learned model — an agronomist has to be able to see why a score is high
A learned layer on top of the published models, calibrated against confirmed local observations where they exist, to adjust thresholds that were derived in a different climate
Leaf wetness estimated from humidity, rainfall, radiation and canopy density, since direct sensors are rare and the published models were written assuming them
Accumulated infection pressure tracked across the season, because a single infection period means less than four in succession
Growth-stage weighting applied so the same weather produces different risk at different susceptibility windows
Inoculum presence handled as a separate, explicitly uncertain input rather than folded into the weather score — conditions suiting a pathogen that is not present produce no disease
Validation against confirmed scouting observations and, where available, regional disease incidence, reported per pathogen rather than as a single accuracy figure
Monitoring for weather input gaps, since a missing humidity series silently suppresses risk scores that should be high

What it changes for the business

Input efficiency

Risk-based timing avoids applications in seasons where conditions never supported infection.

Yield protection

Alerts in high-pressure seasons catch the applications that a calendar programme would have missed.

Agronomist leverage

Scouting prioritisation puts limited field-walking time on the fields that warrant it.

Resistance stewardship

Fewer unnecessary applications supports the resistance management requirements growers face.

How it fits into your product

How it embeds

Field geometry as GeoJSON or referenced from boundaries your platform already stores
On-farm weather station ingestion where growers have them, blended with gridded data
Alerts via webhook into your agronomy app, SMS or email workflows
Scouting recommendations shaped for mobile field use, not just dashboard display
White-label delivery for input retailers and cooperatives serving growers
Model provenance in every response so advice can be defended to an agronomist

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 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

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

Can you tell us whether a field is actually infected?

No. The API scores whether conditions favoured infection, which is a different claim. Disease requires both suitable conditions and the pathogen being present, and satellite and weather data cannot confirm presence. That is why every high-risk response carries a scouting recommendation rather than a diagnosis. The field inspection is not an optional extra step; it is where the actual confirmation happens.

Should this drive spray decisions automatically?

We would not build it that way. Fungicide application is an agronomic and in places a regulated decision involving product choice, resistance management, label restrictions and withholding periods. The API is an input to that decision and we would present it as risk and evidence, not as an instruction. A platform that turns a risk score directly into a spray recommendation is taking on advisory responsibility it should think carefully about.

How good is the regional surveillance data?

Uneven, and that is a genuine weakness. Some countries and crops have well-funded monitoring networks publishing weekly; others have nothing usable, and some of what exists carries terms that prohibit commercial use. Where surveillance is absent the API returns the weather-driven risk with inoculum status marked unknown, which is less useful and honest about being so.

Which pathogens can you cover?

Those with published, validated infection models — which covers the major fungal diseases of cereals, potatoes, vines and several field vegetables well. Pests and bacterial diseases are patchier, and for some there is no model worth implementing. We would list exactly which crop and pathogen pairs are supportable during discovery rather than promising a catalogue we would then have to invent.

Do the published models work in our climate?

Not always without adjustment. Many were derived in specific regions and their thresholds do not transfer cleanly. Where you have confirmed local observations we calibrate against them, and where you do not we would run the published model as published and say that it is uncalibrated for your conditions. Pretending otherwise is how these systems lose agronomist trust in the first season.

All Agriculture & Environment offers →

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.

Discuss This Build Browse All Offers