Case study
Flora API: plant data built for a changing climate.
A plant species API that joins native status, county-level distribution, and climate projections in one place, built because the field had no single source that did.
The challenge
Anyone building a native plant tool hits the same wall: where does the plant data come from?
We needed reliable plant data for our own tools, starting with a map-based native plant finder. The essentials were clear: whether a plant is native or invasive in a given place, where it actually grows down to the county, and the characteristics that help people grow it, such as height, bloom time, sun, and soil.
Plenty of plant databases existed, but none had everything. Some were expensive, some were incomplete or abandoned, and others were static downloads that were never meant to power an app. Almost none combined native status with county-level distribution, and none looked ahead to how a changing climate would reshape where plants can thrive.
Plenty of plant databases existed. None had everything a native plant tool needs.
That gap wasn't just ours. Researchers, conservation groups, nurseries, landscapers, and app developers were all piecing the same data together by hand. So we set out to build the resource the field was missing, and to make it open to anyone who needs it.
Approach
Good data products are designed, not just collected. Most of the work happened before a single endpoint existed.
Source research and precedence
We spent weeks evaluating public botanical databases, government records, and open scientific sources. The foundation is the USDA PLANTS Database, which covers both county-level records and native status by region. Other public sources add characteristics, growing conditions, and propagation details. Where sources overlapped, we mapped exactly which one to trust for each field, weighing richness against coverage.
Standardizing messy data
Real-world botanical data is inconsistent. One source described a plant's habitat as a sentence ("cool, wet regions in coniferous forests") and the next as a list ("Woodland, Riparian, Marsh"). We designed a controlled vocabulary and normalized every record into clean, filterable tags, so a search for wetland plants returns all of them.
A schema built for scale
The database had to hold 28,000+ species and more than two million county distribution records across 3,200+ U.S. counties, alongside taxonomy, characteristics, and growing conditions, and still answer queries quickly. We designed a normalized PostgreSQL schema with dozens of lookup tables, so filters stay fast and new data slots in cleanly.
A pipeline we can trust
We used a suite of Python scripts to gather data from each source, chaining identifiers from one source to access data in another, and load everything into the new schema. All told, processing took roughly 70 hours.
The work
A production REST API with 30+ data endpoints, documentation written for both developers and non-developers, and a public tool built on top.
Search, species, and distribution
The most-used endpoints search the full database by name, state, flower color, plant type, bloom time, and native or invasive status, and return detailed species profiles. The distribution endpoints show exactly where each species grows at the state and county level, the data that took the most effort to compile and that few other APIs offer. Other endpoints cover native species lists by region, conservation status, edible plants, and related species.
A climate engine
Our biggest addition turns Flora from a lookup into a planning tool. It combines a 27-variable climate model, built from WorldClim baselines plus derived growing variables such as heat days and chill hours, with each species' climate envelope at county resolution. Projections under the RCP 4.5 and 8.5 scenarios run to the 2050s and 2080s. Nine climate endpoints cover climate match scoring, viability analysis, at-risk species, resilient planting recommendations, migration patterns, and county-level climate reports.
Built-in protection
An open data API needs to stay open without being abused. Flora ships with tiered rate limiting, automated abuse detection that spots coordinated scraping across accounts and throttles before it suspends, client identification that can't be spoofed with forged headers, and an IP blocklist. Real users keep their access, and bad actors don't get a free copy of the database.
Documentation for everyone
Alongside the interactive OpenAPI reference, we wrote a plain-English guide that explains every endpoint without code, so a parks planner can judge what Flora can answer before a developer writes a line.
How it fits together
Impact
Flora has grown steadily since launch, and it's shaping the tools other teams build.
- 28,000+plant species
- 2M+county distribution records
- 280+developer accounts
- 2.5×monthly active API users since August
Developers sign up every week, around 20 a month, and the number of accounts actively calling the API each month has grown 2.5× since August.
From a manual list to seconds
One of Flora's most important features came from a single conversation. A municipal parks department in Texas reached out: they were building a list of climate-resilient plant species for their county by hand, and wanted to know if Flora could help. At the time it couldn't. That request led directly to Flora's climate engine, which turns their manual process into a single query that anyone can now run for any county.
Proof that good data, designed well, solves real problems for real people.
Working on something similar?
Let's build something for the planet.
Whether you have a dataset that needs a product, or a product that needs a better experience, we'd love to hear about it.
Next project
Companion Planter
An interactive companion planting chart and bed planner. Case study coming soon.