Methodology
Commercial Products
Commercial User GuideHobbyist and Research Products
Help & Support
What you need to know when requesting data through the Solcast API
What does 'request' mean? How many requests does it take to get the data you need.
What is an API request?
If you've checked out our pricing page, or the Solcast API Toolkit, you'll have likely noticed we talk about 'requests' in reference to our data products.
Solcast calculates an individual API request using the following formula:
The definition of a location can be a combination of latitude and latitude or a resource ID (for advanced PV).
If you make a request using a resource ID and would like to make the same request for radiation and weather, you will need to ensure that the latitude and longitude values are identical to the values used for the Advanced PV site. If they are different, it will be considered two locations.
An API endpoint can be any of the following:
- Radation and Weather
- Rooftop PV Power
- Advanced PV Power
Our common file formats:
- HTML (default file format if no other value is provided)
- JSON
- CSV
- JSON Columnar
What is the output data duration of the request?
For TMY data products, one request is equivalent as One Location X One (TMY) Year of Data.
For Historical Time Series data, one request is calculated as One Location X One Month of Data.
For Live and Forecast data, each request is calculated as One Location X Requested Forecast/Live Duration of Data.
For example if you made a csv request at Bondi Beach in Australia for Radiation and Weather, and then using the exact same latitude and longitude for Bondi Beach but instead for Rooftop PV Power, you will have used 1 location allowance and 1 request for Radiation and Weather and 1 request for Rooftop PV Power. You can see this breakdown in your Managed Subscription view within the Solcast Toolkit.
For evaulation users, each product endpoint will have it’s own unique limit. Please see Manage Subscription to view specific limits.
There are 3 limitations on the Solcast API.
- Rate limit (per product) - Standard limits are: Live and Forecast (L&F) 1,000/min, TMY 30/min, TimeSeries 60/min. Exceeding the rate limit will return an error with the message "Rate Limit Exceeded"
- Location limit (per product) - A count of the number of unique lat/lons for which data has been requested. For L&F, this resets daily. For TMY and TimeSeries, this can be configured to reset either monthly or yearly depending on need. This number is defined by commercial scope. Exceeding the location limit will return an error with the message "Unique Locations Limit Exceeded"
- Request limit (per endpoint) - The number of API calls that can be made to a particular endpoint. This number is defined by product choice. Exceeding the request limit will return an error with the message "Transaction Limit Exceeded"
Read our API documentation for further detailed information.
Example Monthly TMY Plan:
- TMY plan, for up to (5) unique locations each month
- Location limit = 5, which resets every month
- Requests for TMY plans are 10x the number of locations, so you'd have 50 requests
- This allows for 5 unique TMYs to be accessed within a 30 day period (each month). The reason for including 50 requests is to enable access to multiple parameters or file types for each location. For example: Setting probability of P50 or P95 and export format as a csv or json or PVsyst format or SAM format.
- 1 request = 1 location x 1 (typical meteorological years worth of data)
Example Monthly Time Series Plan:
- Time Series Starter plan, for up to (1) unique locations each month
- Location limit = 1, which resets monthly
- 1 request = 1 (location) x 1 (month of data)
What happens if I’ve run out of request?
In most instances the user’s API request limits are set to reset per Coordinated Universal Time (UTC) day.
This means that the quota of API requests available to the user will refresh at the beginning of each UTC day, providing a standardised and globally recognised time reference. It's crucial for users to be mindful of this reset timing to effectively manage their API usage and ensure uninterrupted access to the desired services. By aligning with the UTC day, this approach ensures a consistent and fair allocation of API resources for users across different time zones, promoting a streamlined and equitable experience for all.