Solargis API User Guide
- 1 Overview
- 2 Origin of the solar data
- 3 Origin of the meteorological data
- 4 DataDelivery Web Service
- 4.1 XML request
- 4.1.1 Root
- 4.1.2 Processing
- 4.1.2.1 Data parameters
- 4.1.3 Units of solar and PV data parameters
- 4.1.4 Site
- 4.1.5 PV system
- 4.1.6 XML request examples
- 4.1.6.1 Example of all options (full request)
- 4.1.6.2 Example of fixed mounted PV system
- 4.1.6.3 Example of tracking PV system with one horizontal axis in the north-south direction
- 4.1.6.4 Example of tracking PV system with one inclined axis in the north-south direction
- 4.1.6.5 Example of tracking PV system with one vertical axis
- 4.1.6.6 Example of tracking PV system with two axes
- 4.2 XML response
- 4.1 XML request
- 5 Push Delivery
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.
| 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
| timeseries | YES | YES | YES | YES | NO | synchronous | XML | XML | stateless |
Long-term Averages Web Service (LTA API) | 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 https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/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 https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/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 |
|---|---|---|---|
historical | satellite model |
| 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 |
| Operational stage of the solar data is created as soon as the calendar day is completed at the location. |
real-time | satellite model |
| The real-time data stage is actually ending shortly before the current time due to processing delays of the satellite model. |
nowcasting | satellite model |
| 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 |
| 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 https://solargis.atlassian.net/wiki/spaces/public/pages/7602367/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).
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)
Data processing delay (including retrieval, preprocessing and nowcasting model run) takes 5-15 min. Data is available immediately after the data processing is finished.
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
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 |
|---|---|---|
ERA5 reanalysis of the global climate (ECMWF) |
| 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) |
|
|
GFS forecast model (NOAA) |
|
|
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 Python, Java, PHP. For all other technical details visit this link.
XML request
Root
element name | dataDeliveryRequest |
|---|---|
defined in | |
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 | |
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 |
|---|---|---|
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 |