🌱 n8n-nodes-leafengines USDA Soil + EPA Water + NOAA Climate → Environmental Automation Node

Tips & Tricks
1

npm install n8n-nodes-leafengines

I’ve been building environmental automation workflows that combine:

  • USDA soil composition

  • EPA water quality

  • NOAA climate data

  • Satellite vegetation embeddings

Stitching these APIs together repeatedly got messy, so I packaged them into a custom n8n node.

Would love feedback from anyone building ag-tech, climate, or land evaluation workflows.

:white_check_mark: What It Currently Does

  • USDA soil composition lookup (by county FIPS)

  • Multi-source environmental impact scoring

  • Tier-gated API credentials (free + pro)

  • Designed for self-hosted n8n

  • No manual TypeScript build required

  • Direct npm install

Two endpoints are available in the free tier right now.

:sheaf_of_rice: Free Tier Endpoint

get_soil_data

Retrieves USDA soil composition for a US county.

Returns:

  • pH

  • N-P-K nutrients

  • Organic matter %

  • Drainage class

  • Texture

Requires:

  • 5-digit county FIPS
    (Call county_lookup first if you only have a place name.)

Output:
Structured JSON suitable for scoring or cross-county comparisons.

:globe_showing_europe_africa: Pro Tier Endpoint

environmental_impact_analysis

Combines:

  • USDA soil data

  • EPA water quality

  • NOAA climate

  • AlphaEarth 10m satellite embeddings

Returns:

  • runoff_risk (0–100)

  • contamination_risk (low / medium / high)

  • biodiversity_impact

  • carbon_footprint_score

  • Vegetation health indicators

Use cases I’ve been testing:

  • Environmental due diligence

  • Land acquisition pre-screening

  • Carbon reporting workflows

  • CRM-based land qualification

  • n8n ≥ 0.198.0

  • Node.js ≥ 16.x

Uses modern n8n API patterns (functionArgs.getNodeParameter(), async credentials, NodeConnectionType.Main, etc.).
No deprecated this. usage.

:package: Repo + Sample Workflows

Full workflow JSON examples and setup notes:

:backhand_index_pointing_right: GitHub README: Get it here.

Includes:

  • Importable sample workflows

  • Credential setup

  • Example webhook payloads

  • Suggested Airtable schema

:thinking: Open Questions (Would Appreciate Input)

  1. Would people prefer:

    • Separate nodes per data source?

    • Or one consolidated environmental scoring node?

  2. Is tier-gating inside a community node acceptable, or better handled externally?

  3. Are there other ag / environmental APIs you’d want bundled?

  4. Would a Postgres-native scoring example be more useful than Airtable?

:brain: Why I’m Sharing This

I’m experimenting with turning environmental data pipelines into reusable automation blocks instead of custom glue code per project.

If others are working in:

  • Ag-tech

  • Carbon markets

  • Land acquisition

  • Environmental compliance automation

I’d love to compare approaches.

Happy to iterate this based on feedback.

If it’s useful, I can expand the free tier or add additional example workflows.

2

@QWarranto you are welcome,
and great work on this node, it is a very interesting addition for environmental and geospatial automation.

From my perspective, this fits very well in workflows where people already use platforms like Google Earth Engine for remote sensing and large-scale geospatial analysis, while n8n handles orchestration and integration around those services. For the database side, Oracle Spatial is a strong and well-established option in enterprise GIS, though many users also work heavily with PostGIS and other spatial stacks.

One point I would especially value is the accuracy and validation side. Environmental data often comes from multiple sources with different resolutions, temporal coverage, and uncertainty levels, so it would be very useful to understand how the node reports confidence, handles validation, and exposes data quality checkpoints.

That kind of transparency would make the workflow much more reliable for real world analysis and decision making.

1 Like
3

Thanks very much. Those are great points on data quality transparency. It’s core to what we built.

Every LeafEngines API response includes a machine-readable data_quality envelope with:

  • Overall confidence score (0–100) and letter grade (A–F)

  • Per-source metadata — provider name, live/cached/fallback status, freshness (hours since last update), and spatial resolution

  • Validation flags — explicit alerts when data is estimated, interpolated, or sourced from a fallback provider

This is designed specifically for the workflow automation use case you’re describing. In n8n or Node-RED, you can branch on overall_confidence < 70 to route low-quality results to manual review, or filter by source.status === “fallback” to flag degraded inputs before they hit downstream PostGIS analysis.

The scoring is versioned (scoring_version) so if we refine the algorithm, your existing thresholds remain reproducible and auditable.

For multi-source workflows combining USDA, EPA, and NOAA — which is exactly our core pipeline — each source reports independently, so you can pinpoint which layer is degrading confidence rather than getting a single opaque number.

We’d welcome feedback from anyone stress-testing this against real spatial stacks. The envelope schema is stable in SDK v2.2.0 and documented in our OpenAPI spec. Implementation is underway. Included in the update are (1) having each engine function collect source metadata as it runs, and, (2) a response wrapper that assembles the envelope before returning. SDK3.0 is targeting May.

1 Like
4

Using AlphaEarth 10 m satellite embeddings is wonderful. The 10 m spatial resolution is very promising for crops, soil, and other land applications. Thank you very much, and good luck with the project.

Do you have any plan to use Aqua or Terra MODIS data as well? It could be a valuable addition, especially for broader temporal monitoring and change detection.

1 Like
5

Thanks for the endorsement on AlphaEarth — the 10m Sentinel-2 embeddings are really the backbone of our field-level analysis.

Great question on MODIS. We don’t currently ingest Aqua/Terra MODIS directly, but it’s on our radar for exactly the use case you describe — broader temporal baselines and change detection at coarser resolution. The 250m–1km MODIS grid complements Sentinel-2’s 10m nicely: MODIS gives you daily revisit for trend detection (drought onset, phenology shifts, burn scar monitoring), while Sentinel-2 gives you the spatial precision for field-level decisions.

Architecturally, it would slot in as an additional source in our multi-source pipeline, with its own entry in the data_quality envelope — so you’d see modis_terra or modis_aqua reporting independently with resolution, freshness, and confidence, just like our USDA/EPA/NOAA layers do today.

No firm timeline yet, but it’s a natural fit for our post-SDK 3.0 roadmap. If you have specific MODIS-derived indices (LST, EVI, fire hotspots) that would be most useful in your workflows, I’d love to hear — it would help us prioritize which products to surface first.

1 Like
6

Thanks for the detailed explanation, that makes a lot of sense.

I have a long background in remote sensing, and these days I mostly work with very high resolution data for target detection in complex workflows that are not really suited for publication, which makes this kind of multi-source design especially interesting to me.

I really like the idea of keeping MODIS as a separate source in the data_quality envelope, with its own freshness and confidence metadata. That feels like a clean way to combine daily trend detection from MODIS with the field-level precision of Sentinel-2.

For MODIS, the most useful products for my work would probably be LST and EVI first.

1 Like