A Plant Health Diagnosis API: One Image In, Structured JSON Out

You have a product that sees plants: a grow camera, a controller, a garden app, a greenhouse dashboard. You want it to say something useful about plant health. The obvious path is to train your own vision model, which means collecting labelled images, standing up training infrastructure, and then owning the much harder second job forever - knowing when your model is wrong. Most teams do not want that job. They want an answer they can trust and a JSON response they can build on.

That is what a plant health diagnosis API is for. You POST an image, you get a structured result back, and the hard part is somebody else’s problem: the model, the calibration, the honesty about being unsure.

What a good response actually contains

The point of an API, versus a chatbot that writes a paragraph, is that the answer is structured and machine-readable. A single image goes in. What comes back is a compact object your code can branch on - not prose you have to parse. Illustratively:

{
  "schema_version": "3.1.0",
  "results": [
    {
      "is_healthy": false,
      "health_confidence": 0.10,
      "growth_stage": "flowering",
      "growth_stage_confidence": 0.9,
      "conditions": [
        {
          "class_id": "powdery_mildew",
          "display_name": "Powdery Mildew",
          "confidence": 0.95,
          "coarse_group": "fungal_disease"
        }
      ],
      "reliability_score": 0.98,
      "bbox": { "x0": 0, "y0": 0, "x1": 1, "y1": 1, "normalized": true }
    }
  ]
}

This is a cannabis example. Response fields vary by plant. Reliability is optional for some unhealthy cannabis results. Tomato does not return growth stage or verification. Read the current API contract.

Structured results for integrations

A photo-based result can be wrong. Inspect the plant before treatment, and compare symptoms with other possible causes.

PlantLab returns structured fields that an integration can read. PlantLab is currently free to use. You can log a result, request another photo, or ask a person to review it before an action.

Fields to read before taking action

Read these optional fields when the response includes them.

The reliability signal differs from condition confidence. It is an optional estimate for some unhealthy cannabis results. Use it alongside your observations, not as a guarantee that a diagnosis is correct.

The condition group. Some cannabis condition results include coarse_group. Read it when present alongside confidence and your observations.

Where it drops in

Because the answer is structured JSON, it goes wherever your stack already is. It runs as a step in a Home Assistant automation or a Node-RED flow, behind a camera that fires on motion or on a schedule, or inside your own app’s upload path. There is a worked Home Assistant plant-monitoring walkthrough if you want a concrete integration to copy.

The audience this fits: hardware makers who want plant-health detection on the box without building an ML team, app developers who want a diagnosis feature without owning a model, and AgTech integrators who want one detection layer that speaks JSON across their platform.

Honest about scope

A diagnosis API is only as good as its honesty about what it covers. PlantLab supports tomato and cannabis diagnosis, with different coverage for each plant and further plants planned - and a crop is never called “live” in the API before a real model does the work. If your product needs a crop that is still on the roadmap, that is a straight answer you can plan around, not a silent wrong result. The reasoning behind building one crop at a time is in A Plant Lab, One Crop at a Time.

Try it

There is a free tier, so you can send a real image and read a real response before writing a line of integration code. Grab a key and the schema at plantlab.ai - one image in, structured JSON out.