PlantLab.ai | Blog

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 }
    }
  ]
}

Check the live docs for the full schema, but the shape is the point. Every field is something your integration can act on: the condition (class_id) and its confidence, the clinical family it belongs to (coarse_group), a reliability_score for that result, its growth_stage, and a bbox for each plant when more than one is in frame.

Why not just call a general vision model

You can hand a plant photo to a general-purpose vision model and get a fluent answer. Two things go wrong at scale.

It over-calls, confidently. A general model produces a confident-looking answer whether or not it has any basis for the call, and it has no idea when it is wrong. Wire that into automation and you will act on your worst inputs, because the confidence number means the least exactly when the photo is hardest.

It is prose, not data, and it is not cheap. You pay per call for a paragraph you then have to parse, normalize, and second-guess. A purpose-built diagnosis API returns fixed fields in a few milliseconds, at a cost that survives running on every frame or every upload.

The value is not “an AI looked at your plant.” It is a calibrated, structured answer you can put a threshold on.

The fields that make it safe to automate

Two fields in that response exist specifically so you can automate without getting burned.

The reliability signal is separate from confidence. Confidence is how hard the model leaned; reliability estimates how much to trust this answer on this specific image. Gate your automation on reliability, not raw confidence, and low-quality photos stop triggering actions. That distinction is the whole reason the field exists.

The family. Every condition comes back with its clinical family, its coarse_group. When two conditions genuinely cannot be separated from a photo, that family is what your logic acts on: alert, log, or ask for a better photo, rather than commit to a coin-flip between two exact names. An honest “it's in this group” is more automatable than a precise guess.

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's live model today diagnoses 30 conditions in cannabis, with tomato in development and further crops on a public roadmap – 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, in about 18 milliseconds.