Solargis API User Guide

Solargis API User Guide

This content is now outdated due to the upgraded version of the Monitor & Forecast API and the API LTA - effective from May 28, 2025. Please, read API releases and follow the new public documentation at Introduction

Overview

The purpose of the Solargis API (specifically the Solargis WS API) is to provide flexible automated access to various Solargis products - namely for Monitor, Forecast and Prospect solutions.  Developers can automate the integration of Solargis products into customized solutions.


WS API endpoints

Response dataset type

Availability of PV, solar and meteorological data

Technical features

historical

operational

real-time and nowcasting

numerical weather forecasting

long-term average

mode of communication

request formats

response formats

state

DataDelivery Web Service

https://solargis.info/ws/rest/datadelivery/request

timeseries

YES

YES

YES

YES

NO

synchronous

XML

XML

stateless

Long-term Averages Web Service (LTA API) https://solargis.info/ws/rest/pvplanner/calculate

long-term averages, 12 monthly +1 yearly value

NO

NO

NO

NO

YES

synchronous

XML

XML

stateless

Solargis WS API consists of two different endpoints:

  • DataDelivery Web Service - the main service for accessing Solargis timeseries data for Monitor or Forecast. Both request and response are XML documents. The request parameters are based on the XML Schema Definition documents (XSD). By using the schema, request or response can be verified programmatically.  Authentication and rate limiting is based on API key registered with the user. Please contact us to discuss details, set up trial or ask for a quotation. Look for more technical information here and Solargis API User Guide | Data Delivery Web Service .

  • Long-term Averages Web Service (LTA API)  - a simple web service provides monthly long-term averaged data (including also the yearly value) of PV, solar and meteorological data. The service is aimed for automation of prospection and pre-feasibility of PV projects. More information can be found here.

Additionally, Solargis provides the automated Push Delivery service where the request (a CSV file) is stored in the user's remote directory (SFTP, Azure, S3). The service is then scheduled to push CSV data files regularly e.g., once a day or every hour. The CSV request allows for multiple locations in a single file. The availability of data is the same as with the DataDelivery Web Service. For pricing and setting up a trial account, please contact us. For more information see Solargis API User Guide | Push data delivery .

Origin of the solar data

The main solar data parameters include GHI, DNI, DIF. The main calculated parameters are GTI and PVOUT.

The table below shows how the solar data are integrated into the API response (in case of timeseries in the DataDelivery Web Service):

Stage of the solar data

Origin of data

Validity period

Description

Stage of the solar data

Origin of data

Validity period

Description

historical

satellite model

  • Start: the beginning of the archive

  • End: the last completed calendar month (MONTH-1)

Data for any location enters this stage upon completion of the calendar month. The reanalysis of the previous month takes effect on the 3rd day of each calendar month. Historical data can be regarded as final or of archive quality. The oldest solar data stored by Solargis dates back to 1994.

operational

satellite model

  • Start: the beginning of the current calendar month

  • End: the last completed calendar day (DAY-1)

Operational stage of the solar data is created as soon as the calendar day is completed at the location.

real-time

satellite model

  • Start: the beginning of the current calendar day (DAY+0)

  • End: the current time

The real-time data stage is actually ending shortly before the current time due to processing delays of the satellite model.

nowcasting

satellite model

  • Start: the current time

  • End: 4 hours after the current time

The beginning of this stage at the current time is approximate. The nowcasting data is generated from the series of satellite scenes. Solargis predicts solar data parameters by utilizing CMVs (Cloud Motion Vectors). After approximately 3-4 hours, the satellite nowcasting model output begins to blend with the numerical weather prediction data.

numerical weather prediction (NWP)

post-processed outputs of NWP models

  • Start: 4 hours after the current time

  • End: DAY+14 (15 days in a row including the current day)

The NWP based solar data is asembled from multiple NWP data sources: IFS forecast model (ECMWF), ICON forecast model (DWD), GFS forecast model (NOAA), HRRR model (NOAA). Find more information about the forecasting here.

Obtaining information about the origin of solar data is possible by using the CI_FLAG parameter (Cloud Identification Quality Flag) in the XML request. In the response, each record will be flagged with the following categories:

  • 0: sun below horizon

  • 1: model value

  • 2: interpolated <=1hour

  • 3: extrapolated <=1hour

  • 4: interpolated/extrapolated >1hour

  • 5: long term monthly median or persistence

  • 6: synthetic data

  • 10: nowcast

  • 11: NWP forecast

It is recommended to use and interpret the CI_FLAG values with the finest solar data resolution i.e., 15 or 10 minutes.

Reanalysis of the historical and operational solar data

The timeline of calculation of solar data at the location is as follows:

  • Every day, solar irradiance data is calculated for DAY-1 and DAY-2.

  • At the beginning of each month, solar irradiance data for the previous month is re-calculated using the final atmospheric data inputs. Atmospheric data are homogenized with historical data records to avoid abrupt changes due to atmospheric models changes.

Find more details in this article.

Spatial availability of the satellite data

  • Regions with the orange color are updated every few minutes (satellite based real-time and nowcasting models are available in the current day). 

  • In the yellow regions the satellite data is updated every day (so that the DAY-1 is available). For the timing of updates, see Solargis API User Guide | Description of the satellite data regions.

Overview of satellite data sources

Map of satellite data regions

Description of the satellite data regions

satellite data region

historical data start

description of satellites

when the local DAY-1 is available

real-time and nowcasting availability

GOES WEST

1999-01-01

2019+: GOES-S, 10-minute time step

2018 - 1999:  GOES-W, 30-minute time step

09:00 UTC

Satellite data availability delay is 2-12 minutes and it increases from south to north. Processing frequency is every 10 minutes and it takes another 5-15 minutes.

GOES EAST

1999-01-01

2019+: GOES-R, 10-minute time step

2018+: GOES-R, 15-minute time step

2017 - 1999:  GOES-E, 30-minute time step

05:00 UTC

same as the GOES WEST region

GOES EAST PATAGONIA

2018-01-01

2019+: GOES-R, 10-minute time step

2018+: GOES-R, 15-minute time step

05:00 UTC

same as the GOES WEST region

METEOSAT PRIME SCANDINAVIA between 60°and 65° latitude

2005-01-01

2005+: MSG 15-minute time step

00:30 UTC

not yet

METEOSAT PRIME

1994-01-01

2005+: MSG 15-minute time step

2004 - 1994:  MFG, 30-minute time step

00:30 UTC

Satellite data availability delay is 2-16 minutes and it increases from north to south. Processing frequency is every 15 minutes and it takes another 5-15 minutes.

METEOSAT IODC

1999-01-01

2017+: MSG 15-minute time step

2016 - 1999:  MFG, 30-minute time step

19:00 UTC 

same as the METEOSAT PRIME region

IODC-HIMAWARI

1999-01-01

2017+: HIMAWARI 10-minute time step

2016 - 1999:  MFG, 30-minute time step

16:00 UTC

same as the HIMAWARI region

HIMAWARI

2006-07-01

2016+: HIMAWARI 10-minute time step

2015 - 2006:  MTSAT, 30-minute time step

16:00 UTC

Satellite data availability delay is 5-15 minutes and it increases from south to north. Processing frequency is every 10 minutes and it takes another 5-15 minutes.

To request historical data in the areas out of coverage, please use Solargis Evaluate or contact us.

Nowcasting data availability and delay

Total delay of the near real-time data is a combination of satellite data availability delay, data processing delay and the user request delay (after processing is finished).  

  1. Primary satellite data availability delay after actual scanning of a location depends on its latitude and satellite region as follows:

    • PRIME, IODC - delay is 2-16 minutes  (increases from north to south) 

    • HIMAWARI - delay is 5-15 minutes  (increases from south to north)

    • GOES-EAST & WEST (excluding Contiguous US) - delay is 2-12 minutes  (increases from south to north)

    • Contiguous US - delay is 2-6 minutes  (increases from south to north)

  2. Data processing delay (including retrieval, preprocessing and nowcasting model run) takes 5-15 min. Data is available immediately after the data processing is finished.

  3. Processing frequency is 10 minutes (HIMAWARI, GOES-EAST & WEST), 15 minutes (PRIME, IODC), or 5 minutes (Contiguous US). In other words, each new satellite image trigger run of another nowcast run. The processing frequency also determines the window when any given nowcast run is available for delivery (i.e. before it is replaced by the next run). The timing of a customer's request with respect to this interval represents the user request delay, which is thus in the range 0-10, 0-15 minutes, or 0-5 minutes for the respective nowcasting region (see map below).

Nowcasting and forecasting update frequency

Solargis-FORECAST-NOWCAST-NWP-data-coverage-map-v202501.png
Update frequency (and thus the recommended access frequency of API products)
of Solargis data for short-term forecasting and nowcasting

Origin of the meteorological data

The main meteorological data parameters include TEMP, WS, WG, WD, PREC, RH, PWAT, AP. Solargis uses the post-processed outputs of global numerical weather prediction (NWP) models for all meteorological data parameters.

The table below shows how the meteorological data are integrated into the API response (Data Delivery Web Service timeseries):

Origin of data

Validity period

Description

Origin of data

Validity period

Description

ERA5 reanalysis of the global climate (ECMWF)

  • Start: the beginning of the archive

  • End: DAY-11

The TEMP data parameter is extracted from the ERA5-Land reanalysis dataset (ECMWF). Important note: ECMWF provider can have delays which can affect the availability of the ERA5-Land dataset.

IFS forecast model (ECMWF)

  • Start: DAY-10

  • End: DAY+3

 

GFS forecast model (NOAA)

  • Start: DAY+4

  • End: DAY+14

 

Find more information about the forecasting here.

DataDelivery Web Service

The client will send the XML request and wait for the XML response. Users can test web services directly by using applications like Postman. Before sending requests user must set the HTTP Method to "POST", define endpoint URL to https://solargis.info/ws/rest/datadelivery/request?key=demo and add the request header "Content-Type: application/xml". Then use one the XML request examples below and include them in the body of the HTTP request and explore XML responses. Typically, developers will create client code to send requests and handle responses. For creating the client code, we provide samples for PythonJavaPHP. For all other technical details visit this link

XML request

Root

element name

dataDeliveryRequest

defined in

http://solargis.info/schema/ws-data.xsd

description

The root element of the XML request is the <dataDeliveryRequest> with required attributes 'dateFrom' and 'dateTo' for setting desired data period in the response. Accepted is a date string in the form of  ''YYYY-mm-dd" e.g., "2017-09-30". It is assumed UTC (GMT+00) time zone for both dates unless otherwise specified by the <timeZone> element of the <processing>.

content

required one <site> , required one <processing>

@dateFrom*

start of the data period, ''YYYY-mm-dd"

@dateTo*

end of the data period, ''YYYY-mm-dd"

Explanation of the table above: The 'element name' is what you can see in the XML request, e.g., <dataDeliveryRequest>. If the element is of simple type, the content is a literal (text or number), otherwise the content can be list of another <element> or none. Attribute of the element is prefixed by the '@' character. Required attributes are marked by '*' character.

Size of the date period (dateFrom, dateTo) in a single XML request is by default limited to 31 calendar days regardless of the Processing.summarization.

Processing

element name

processing

defined in

http://solargis.info/schema/data-request.xsd

description

Complex element with instructions about how response should be generated.

content

optional one <timeZone>, optional one <timestampType>

@summarization*

required, time frequency in the response. One of MONTHLY, DAILY, HOURLY, MIN_30, MIN_15, MIN_10, MIN_5

@key*

required, text value, output data parameters separated by white space. Example: key="GHI GTI TEMP WS PVOUT". See below table for all supported parameters.

@terrainShading

optional, boolean, if 'true', the distant horizon taken from SRTM data is considered, default is 'false' (no horizon obstructions at all), Note: a user can also apply custom horizon data by providing <horizon> element within the <site> element

Data parameters

Table of available data parameters in XML requests:

parameter

description

tier

parameter

description

tier

GHI

Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]. Regarding units see below note.

Basic

GHI_C

Clear-sky Global Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]

Professional

GHI_UNC_HIGH

GHI high estimate (10 % probability of exceedance) [kWh/m2, Wh/m2, W/m2]

Professional

GHI_UNC_LOW

GHI low estimate (90 % probability of exceedance) [kWh/m2, Wh/m2, W/m2]

Professional

DNI

Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]

Basic

DNI_C

Clear-sky Direct Normal Irradiation [kWh/m2, Wh/m2, W/m2]

Professional

DIF

Diffuse Horizontal Irradiation [kWh/m2, Wh/m2, W/m2]

Basic

GTI

Global Tilted Irradiation [kWh/m2, Wh/m2, W/m2]

Basic

GTI_UNC_HIGH

GTI high estimate (10 % probability of exceedance) [kWh/m2, Wh/m2, W/m2]

Professional

GTI_UNC_LOW

GTI low estimate (90 % probability of exceedance) [kWh/m2, Wh/m2, W/m2]

Professional

GTI_C

Global tilted clear-sky irradiance [W/m2]

Professional

CI_FLAG

Cloud identification quality flag [categories], this parameter is represented as 'flagR' in the response

Basic

FLAG_R

deprecated alias for CI_FLAG

 

KTM

Deprecated alias of KC. Can be discontinued in future versions.

Professional

KC

Clear-sky index [unitless]

Professional

KT

clearness index, values range (0, 1.1), during the night -9

Professional

PAR

Photo-synthetically Active Irradiation [kWh/m2, Wh/m2, W/m2]

Professional

SE

Sun Altitude (Elevation) Angle [deg.]

Basic

SA

Sun Azimuth Angle [deg.]

Basic

TEMP

Air Temperature at 2m [deg. C]

Basic

TD

Dew Point Temperature [deg. C]

Professional

WBT

Wet Bulb Temperature [deg. C]

Professional

AP

Atmospheric Pressure [hPa]

Professional

RH

Relative Humidity [%]

Professional

WS

Wind Speed [m/s]

Basic

WD

Wind Direction [deg.]

Basic

PREC

Precipitation Rate [kg/m2]

Professional

PWAT

Precipitable Water [kg/m2]

Professional

PVOUT

Photovoltaic Output [kW, kWh]. Regarding units see below note.

Basic

PVOUT_UNC_HIGH

PVOUT high estimate (10 % probability of exceedance) [kW, kWh]

Professional

PVOUT_UNC_LOW

PVOUT low estimate (90 % probability of exceedance) [kW, kWh]

Professional

SDWE

Water equivalent of accumulated snow depth [kg/m2]

Professional

SWE

Deprecated alias of SDWE. Can be discontinued in future versions. SDWE will be returned in a response.

Professional

TMOD

Module temperature [deg. C]. This parameter needs a PV system defined in the request, at least in a mimimal setup like:
<pv:system installedPower="1"><pv:module type="CSI"/><pv:inverter/><pv:losses/></pv:system>

Professional

WG

Wind Gust [m/s]

Professional

WS100

Wind speed at 100 m [m/s]

Professional

WD100

Wind direction at 100 m [deg.]

Professional

SFWE

Water equivalent of fresh snowfall rate [kg/m2/hour] - source ERA5 , the latest data available is approx. one month backward (no data for very recent or forecast period)

Professional

INC

Incidence angle of direct irradiance [deg.], this parameter needs GTI or PVOUT in the request

Professional

TILT

Tilt of inclined surface [deg.], this parameter needs GTI or PVOUT in the request

Basic

ASPECT

Aspect of inclined surface [deg.], this parameter needs GTI or PVOUT in the request

Basic

For detailed parameter description see the https://solargis.atlassian.net/wiki/spaces/public/pages/14975030.

Units of solar and PV data parameters

For sub-hourly data the solar and PVOUT value typically represents instantaneous value (a power measured exactly at the given timestamp), so the PVOUT unit will be the kW (or W/m2 in case of solar irradiance).

For hourly and bigger aggregation, the value represents the amount of energy accumulated or averaged within the agg. interval - the unit is the kWh (or Wh/m2, kWh/m2 in case of solar irradiation).

element name

timeZone

defined in

http://solargis.info/schema/data-request.xsd

description

The element controls the time zone in the response (how all timestamps should be shifted from the UTC). Hourly and half-hourly precision is supported.

content

required, string value in the pattern "GMT[+-][ zero-padded hours ][:30]", default value is GMT+00 (UTC), Examples: GMT-04, GMT+05:30, GMT-02:30

Full request example for the GHI parameter in the India Standard Time (IST) zone:

<ws:dataDeliveryRequest dateFrom='2024-04-19' dateTo='2024-04-19' xmlns='http://geomodel.eu/schema/data/request' xmlns:ws='http://geomodel.eu/schema/ws/data' xmlns:geo='http://geomodel.eu/schema/common/geo' xmlns:pv='http://geomodel.eu/schema/common/pv' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'> <site id='Delhi' lat='28.758009' lng='77.296243' name='Delhi' /> <processing summarization='HOURLY' key='GHI' terrainShading='true'> <timeZone>GMT+05:30</timeZone> </processing> </ws:dataDeliveryRequest>

element name

timestampType

defined in

http://solargis.info/schema/data-request.xsd

description

Simple element provides how aggregated time intervals in the response should be labeled.

Valid for [sub]hourly summarization. Intervals can be time-stamped at the center (default) or at start or at end. In other words, users can choose the left (START) or the right (END) edge of the time interval for its label (besides the center).

content

required, one of START, CENTER, END

Site

element name

site

defined in

http://solargis.info/schema/data-request.xsd

description

Complex element representing site location, optionally with a PV technology installed

content

optional one <geometry>, optional one <system>, optional one <terrain>, optional one <horizon>

@id*

required, site identification, cannot start with number, cannot have white space. It is recommended to use different site id for unique combinations of latitude and longitude. Referring to the specific site id facilitates the troubleshooting of issues in the API. Do not reuse the same site id for multiple locations.

@lat*

required, site latitude in decimal degrees e.g, 48.61259

@lng*

required, site longitude in decimal degrees e.g, 20.827079

@name

optional, more descriptive name of the site (e.g., address), default is empty string

element name

terrain

defined in

http://solargis.info/schema/common-geo.xsd

description

Ground terrain characterized by elevation, terrain slope and terrain azimuth. Terrain properties affect the self shading of a fixed angle PV array (note, that 'tilt' and 'row spacing' attributes of PV modules on the pictures below are identical - what is changing is the terrain slope and how it affects the self shading).

content

none

@elevation

optional, meters above the mean see level. If missing, the value will be taken from SRTM terrain database

@azimuth

optional, orientation of tilted terrain in degrees, 0 for North, 180 for South, clockwise, default is 180, has no effect for the flat terrain (tilt=0)

@tilt

optional, slope tilt of the terrain in degrees, 0 for flat ground, 90 for vertical surface, default is 0 (flat)

element name

horizon

defined in

http://solargis.info/schema/common-geo.xsd

description

User can provide custom skyline for expressing distant or close obstruction features (hills, trees, buildings, poles, etc.)

content

String of this form: space-delimited list of float number pairs [azimuth in degrees:0-360]:[horizon height in degrees:0-90], Example: "<geo:horizon>0:3.6 123:5.6 359:6</geo:horizon>"

element name

geometry

defined in

http://solargis.info/schema/common-pv.xsd

description

Parametrization of PV system mounting type used for calculating GTI and PVOUT. If this element is missing and GTI/PVOUT is requested, flat-lying PV panels are considered (GTI=GHI). Examples:

<pv:geometry xsi:type="pv:GeometryFixedOneAngle" azimuth="180" tilt="25"/>

<pv:geometry xsi:type="pv:GeometryOneAxisHorizontalNS" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/>

<pv:geometry xsi:type="pv:GeometryOneAxisInclinedNS" axisTilt="30" rotationLimitEast="-90" rotationLimitWest="90" backTracking="true" azimuth="180"/>

<pv:geometry xsi:type="pv:GeometryOneAxisVertical" tilt="25" rotationLimitEast="-180" rotationLimitWest="180" backTracking="true"/>

<pv:geometry xsi:type="pv:GeometryTwoAxisAstronomical" rotationLimitEast="-180" rotationLimitWest="180" tiltLimitMin="10" tiltLimitMax="60" backTracking="true"/>

content

none

@type*

required, type of the mounting geometry. Use one from GeometryFixedOneAngle, GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS, GeometryOneAxisVertical, GeometryTwoAxisAstronomical, see table below for pictures.

@azimuth

the value in degrees of a true geographical azimuth (0: north, 90: east, 180: south, 270: west, 360: north --> a compass value) . In the case of 'GeometryFixedOneAngle' the azimuth attribute is required.

In the case of two tracker types (GeometryOneAxisHorizontalNS, GeometryOneAxisInclinedNS) the value is the compass value at which the southern end of the tracker axis is oriented. Regardless of the Earth's hemisphere. With trackers, the value is limited to the range from 135 deg. to 225 deg. inclusive, so the deviation from the north-south line is not bigger than 45 degrees. With trackers, the attribute is optional and it defaults to 180 deg. (which means the southern end of the axis faces to geographical south, so the tracker field is aligned with the north-south line which is the optimal solution for most cases).

@tilt

tilt of panel surface in degrees range (0, 90), 0=horizontal, 90=vertical surface, required for 'GeometryFixedOneAngle' and 'GeometryOneAxisVertical' types

@axisTilt

optional, default is 30 deg., allowed range is (0, 90). Tilt of rotating inclined axis in degrees, 0 = horizontal, 90 = vertical axis, only applicable for 'GeometryOneAxisInclinedNS',

WARNING: if this attribute is missing, the value defaults to 30 degree.

@rotationLimitEast

optional, for trackers only

default values / allowed ranges:

  • default is -180 deg, allowed range: -180, 180. Applies for vertical axis of GeometryTwoAxisAstronomical and GeometryOneAxisVertical trackers.  Rotation limits are in this case defined relative to 0 deg. (initial tracker position regardless of the hemisphere), default range from -180 to 180 deg (e.g., -90 deg. for east and +90 deg. for west)

  • default is -90, allowed range: -90, 90, Applies for the GeometryOneAxisHorizontalNS and GeometryOneAxisInclinedNS. Rotation limits are in this case defined as tilt of tracker table relative to its central position, both limits are typically symmetric e.g., rotationLimitEast=-50, rotationLimitWest=50

The general rule is: negative values are used for the east side, positive for the west side, the same rule applies for both Earth hemispheres).

The value of rotationLimitEast must be smaller or equal than the rotationLimitWest.

@rotationLimitWest

optional, for trackers only

default values / allowed ranges:

  • default is 180 deg, allowed range: -180, 180. Applies for vertical axis of GeometryTwoAxisAstronomical and GeometryOneAxisVertical trackers.  Rotation limits are in this case defined relative to 0 deg. (initial tracker position regardless of the hemisphere), default range from -180 to 180 deg (e.g., -90 deg. for east and +90 deg. for west)

  • default is 90, allowed range: -90, 90, Applies for the GeometryOneAxisHorizontalNS and GeometryOneAxisInclinedNS. Rotation limits are in this case defined as tilt of tracker table relative to its central position, both limits are typically symmetric e.g., rotationLimitEast=-50, rotationLimitWest=50

The general rule is: negative values are used for the east side, positive for the west side, the same rule applies for both Earth hemispheres).

The value of rotationLimitEast must be smaller or equal than the rotationLimitWest.