Solcast Products
Evaluate Data Access
Testing the Solcast data API
Data Modelling
Modelling - FAQs
Solcast API
What is an API request? How many API requests do I need?
Hobbyists and Researchers
Troubleshooting and FAQs
Data Troubleshooting and FAQs
What timezone are the timestamps?User Guides
Subscription ManagementAccount FAQsWhat 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.
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 limits 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 a 429 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 a 429 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 a 429 error with the message "Transaction Limit Exceeded"
How many requests do you need?
In order to determine how many requests you'll need, you may need to consider more than just the number of locations you need data for.
This is because each response formats (API speak for 'file format' or 'file type') count as their own request.
As a practical example - if you need both a CSV and a JSON file for one location, you will need two requests (1x location and 2x file formats) to get access to the data you require.
To figure out how many API requests you need for a month, you can use the computation below:
Read more about our response format options in the API Toolkit or in the docs.
Example 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
- Each API request returns 1 TMY at 1 location
- This allows for 5 unique TMYs to be accessed within a 30day 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.
Example Time Series Plan:
- TimeSeries Starter plan, for up to (1,000) unique locations each month
- Location limit = 1000, which resets monthly
- Each API request returns up to 1 month of data at 1 location
- Requests for TimeSeries plans are dependent on the historic record specific in each plan. For a Starter plan, this is the past 3 years history. Total requests = 1,000 (locations) * 3 (years) * 12 (months - data per request) = 36k requests per month
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.