SolarFarmer 3D API: What a digital first yield engine changes for solar project finance

The yield tools most solar engineering teams rely on were designed for a different era of project finance. An era of simpler projects, looser scrutiny, and engineering teams whose pipelines were small enough that running each project manually through a desktop application was manageable.

That era is ending. Pipelines have grown. Lender scrutiny has tightened. And the projects being built, non-standard racking solutions like agrivoltaic systems, novel tracker configurations, large sites on complex terrain, have outrun what those tools were designed to model.

What has not changed, for most teams, is the workflow. The yield model still lives inside a desktop application. Every project is a separate manual sequence. Sensitivity analysis is queued, not scripted which limits the opportunity to iterate and optimise designs.

SolarFarmer's REST API and Python SDK are built to change that, by making the full bankable physical model programmable, automatable, and easy to integrate into the engineering environment where your team already works.

What the API actually exposes

SolarFarmer exposes intermediate calculations across the modelling chain: irradiance decomposition, shading results, bifacial  gains, inverter performance including power clipping, and the loss factors in between. The API accepts JSON site designs, queues and runs simulations, and returns energy timeseries and loss tables.

The diagram below shows how programmatic access fits acrossthe SolarFarmer modelling chain, exposing intermediate calculation stagesrather than only the final yield output.

For developers, this means the yield number you take to financing is one where every assumption is inspectable — by your own team, by the lender's IE, by anyone who needs to verify the calculation rather than accept an output.

For independent engineers, it means something more fundamental: the ability to reproduce and verify the full yield calculation from first principles, rather than reviewing an output from a model they cannot fully inspect.

This is the difference between reviewing a document and verifying a calculation.

From financing through to operations

The same physical model that produces the pre-construction yield estimate can serve as the performance benchmark once a project is generating. For asset owners, this closes the methodological gap between the yield number that secured financing and the reference calculation used to evaluate actual generation.

The Python SDK: from install to first calculation in a single session

The gap between "this API exists" and "my team is running bankable yield calculations programmatically" has historically been measured in weeks of integration work. Building API payloads, managing authentication, parsing responses, handling edge cases — before any engineering value is delivered.

The SolarFarmer Python SDK compresses the path from API access to first calculation into a single notebook-based workflow: install the SDK, load project inputs, run the calculation and inspect the results.

pip install dnv-solarfarmer

The SDK wraps the full 3D API in a native Python package. It ships with example notebooks, not just documentation, so teams start from working code rather than a blank page. And it meets teams at their current capability level with three workflow tiers included in the same install. Start where your team is comfortable and progress as your workflows demand:

Load & Execute: for teams with existing API files (from the desktop application or previous calculations), including PAN/OND equipment files you already have available. Point the SDK at a folder of inputs, call one function, and get results in a few minutes. No payload construction, no plant definition, just run and analyse. For example:

import solarfarmer as sf

results = sf.run_energy_calculation(
    inputs_folder_path="my_project/inputs",
    project_id="site_alpha",
    api_key="your_key",
    save_outputs=True
)

print(f"Net Energy: {results.net_energy_MWh:.1f} MWh/year")
print(f"Performance Ratio: {results.performance_ratio:.3f}")
print(f"Specific Yield: {results.energy_yield_kWh_per_kWp:.1f} kWh/kWp")

PVSystem : for engineers who want to define a plant from high-level specifications (location, capacity, equipment, mounting) and have the SDK auto-construct the API payload. First screening-level yield result in 5-10 minutes. PVSystem supports design iteration natively, you can clone a plant configuration, adjust parameters, run again, enabling parametric exploration without manual payload editing, so optimisation is bounded by your imagination compute rather than by how many scenarios you have time to configure manually. For example:

from solarfarmer import PVSystem

plant = PVSystem(
    name="5MW Study",
    latitude=40.0, longitude=-75.0,
    dc_capacity_MW=5.0, ac_capacity_MW=4.5,
    mounting="Fixed", azimuth=180.0, gcr=0.4
)
plant.add_pan_files({"Module": Path("data/module.PAN")})
plant.add_ond_files({"Inverter": Path("data/inverter.OND")})
plant.weather_file = Path("data/weather.csv")

# Parametric tilt sweep
for tilt in [20, 25, 30, 35]:
    variant = plant.make_copy()
    variant.tilt = tilt
    variant.run_energy_calculation(project_id=f"tilt_{tilt}", api_key="your_key")
    print(f"Tilt {tilt}°: {variant.results.net_energy_MWh:.1f} MWh")

Advanced Integration : for software developers building custom applications. Pydantic model specify every field in the API payload and data models. Build custom data mappers from proprietary databases, parameterised payload factories for standardised configurations, and multi-step workflow orchestration. All inputs are validated at construction time, so errors surface locally with clear messages before any API call is made.

The structured learning path takes teams from first install through basic energy calculations to portfolio-scale automation. FAQs address the specific integration questions yield engineers encounter. It is designed to get you on-boarded and running simulations as quickly as possible.

At portfolio scale, the value is less about replacing individual studies and more about making repeatable analysis possible across many project variants.

For teams already scripting layout analysis, automating resource assessment, or building internal data pipelines in Python, the SDK drops a bankable yield engine directly into those existing workflows. No new environment to learn. No desktop application to click through. The model is available where your team works.

What portfolio-scale access changes

When the yield model runs programmatically, things that were previously impractical become routine.

Many development teams face the same scaling problem: more projects, more design permutations, and a pipeline that has grown faster than the engineering team supporting it. Hiring alone does not resolve a workflow constraint. The yield model itself needs to become programmable.

With the SolarFarmer API and Python SDK, batch sensitivity analysis across hundreds of design variants runs as code. Loss factor exploration becomes systematic rather than adhoc. Design-space optimisation iterates parametrically rather than manually. The yield calculation stops being a bottleneck checkpoint and becomes a scriptable component of the engineering pipeline.

This is the difference between scaling headcount and scaling capability. For developers whose pipelines have grown faster than their teams, the API is not a nice-to-have — it is the primary productivity argument.

The accuracy behind the API

A programmable yield model is only as valuable as the accuracy of the physics it exposes.

SolarFarmer's median bias of under 1% was validated against real-world generation data across 36 projects totalling 4.4 GWp in 13 countries — 0.1% median bias in theUS study (12 projects, 823 MW DC) and 0.8% in the SEMELA study (24 projects,3.6 GWp). The validation covers 126 equivalent years of operational data. The 3D physical model resolves shading to sub-module level, distinguishing direct versus diffuse irradiance with cell-current-based mismatch. Native sub-hourly modelling at 1-minute to 60-minute resolution captures inverter clipping and rapid irradiance ramps at the temporal resolution they actually occur, rather than approximating from hourly data. Full documentation, example notebooks, and the SDK source are available at the SolarFarmer Python SDK documentation site and on GitHub.

That accuracy figure is not just a headline — it is evidence that IEs and lenders can cite in their own due diligence. When the yield estimate is grounded in observed plant performance across a published validation dataset, the conversation about model risk starts from a stronger position. And because the validation studies — the Addendum to 2021 US Validation (2023) and the SEMELA validation study (2026) — are both published and citable, they provide evidence that IEs and lenders can reference in their own due diligence.

What this accuracy means from financing

SolarFarmer's yield methodology follows the same bankable approach used in DNV advisory engagements. Combined with the published validation dataset above, developers arrive at the financing table with a yield number grounded in evidence that lenders and their technical advisors can evaluate on its merits — not one they need to negotiate into credibility.

For independent engineers, SolarFarmer offers a second credible yield tool — one where intermediate results are programmatically accessible, not locked inside a desktop application. An IE using SolarFarmer is not reproducing the developer's assessment. They are running their own independent analysis, with their own assumptions, using a model validated against real-world generation data. When the developer's yield estimate and the IE's independent assessment converge, that convergence is earned through shared physics and informed inputs, not shared assumptions.

See how SolarFarmer 3D API works in practice

We recently hosted Digital Bankability: Bankable Yield Modelling in Your Python Workflows — a technical walkthrough of how this approach works in practice. Watch the full on-demand webinar.

If the projects in your pipeline are more complex than they were three years ago, and the financing conversations require more rigour than they used to, this is the technical session worth protecting an hour for.