1 Testing Web services
- 1.1 Demo account
- 1.2 SoapUI examples (how to try basic calls to our WS API)
2 LTA Web Service
3 DataDelivery Web Service
4 Implementing client for Web services
5 Security notes
- 5.1 SSL connection certificate
- 5.2 Web Services Security
  - 5.2.1 Namespaces

Testing Web services

Demo account

Demo account is intended for trying technical aspects of our WS API without the necessity for you to have your own WS API key.
It provides full data access to single DEMO microregion (10x10 km) around following location: 48.61259, 20.827079

The demo key can be used for making WS API calls for both of our service types: DataDelivery + LTA (formerly known as pvPlanner) and also for REST + SOAP access.

REST WS credentials:

key: demo

SOAP WS credentials:

username: demo
password: demo

You can use our WS API demo credentials to code and test your own implementation of WS API calls. If you also want to test quality of our data, please ask Solargis sales representatives for free trial access (i.e. access to limited locations / time periods of data with your own WS API free trial key)

SoapUI examples (how to try basic calls to our WS API)

We recommend starting with SoapUI examples - getting them working before you attempt your own implementation. Using SoapUI is very easy:
just install the multiplatform standalone application SoapUI import demo project ws-demo-soapui-project.xml into SoapUI and submit prepared request messages.
The demo project contains DataDelivery and LTA examples preconfigured with #Demo account thus the location is limited to demo region (10x10km)
The REST access examples work out of the box, all that is needed is to just run the requests by clicking on the "Submit" button and you should see successful results of the call. Here is DataDelivery REST access example:

For SOAP access you might need to fill in the following request properties in SoapUI:

Once you get the demo requests working in SoapUI you can then change key for one that was provided to you by our sales representative and alter the XML request according to your permissions (may require change of latitude / longitude / dateFrom / dateTo, processingKeys etc. in the XML request) We recommend that you first create the working request adapted for your specific requirements and you start working on your own implementation only after you validate that the request is working in SoapUI. That way:

if the request is not working in SoapUI you can easily tell that problem is in the XML request its self and not for example in your implementation
if the request is working in SoapUI but not in your implementation you can then tell that the problem is in your implementation and not in the XML request it's self

If you were able to get the demo examples working but you are unable to get the requests working with your own API key, then please try recommendations in our our troubleshooting guide.
For adapting the demo requests to your requirements we recommend that you take inspiration from our example request / response documentation (see the next section). It's best if you start from simple request and adapt it to more complicated ones and
that you validate in SoapUI that the request is still working after each incremental change. Detailed explanation of all the parameters in the request can be found in our Solargis API User Guide

LTA Web Service

click here for request and response examples

DataDelivery Web Service

click here for request and response examples

Implementing client for Web services

Java client implementation guide (full guide here)

Simple PHP client

Simple Python client

Security notes

SSL connection certificate

Production WS endpoint (https://solargis.info/ws) is secured by a certificate signed by globally trusted certification authority DigiCert - more info here

No additional configuration is needed, because DigiCert root certificates are trusted by default in most environments.

Web Services Security

WS request is validated against WS-Security standard UsernameToken with password digest and nonce and Timestamp element.

Example SOAP message header with security token:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" soapenv:mustUnderstand="1">
      <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="UsernameToken-2"
          xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
        <wsse:Username>demo</wsse:Username>
        <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">Kpr8NgKlQI4wE7Ayo9jm0Z2+hIA=</wsse:Password>
        <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">g9t2BO4uHOUQoFH5ugQIng==</wsse:Nonce>
        <wsu:Created>2011-06-21T11:37:38.771Z</wsu:Created>
      </wsse:UsernameToken>
      <wsu:Timestamp xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-1">
        <wsu:Created>2011-06-21T11:37:38.755Z</wsu:Created>
        <wsu:Expires>2011-06-21T11:42:38.755Z</wsu:Expires>
      </wsu:Timestamp>
    </wsse:Security>
  </soapenv:Header>
  <soapenv:Body>
   <!-- Request Message -->
  </soapenv:Body>
</soapenv:Envelope>

Namespaces

Be careful to define all needed namespaces for request message

Public

WS API technical documentation