Suddenly getting lots 429 errors (Daily API request limit exceeded)

[yotkadata]

I am am using the API for my MeteoHist App at https://yotka.org/meteo-hist - thank you so much for this great API! It does not have much traffic, yet since yesterday I noticed lots of 429 responses (Daily API request limit exceeded). The same happens after one API call from my local machine and also on the website of the Historical Weather API.

I am pretty sure that the app is far under 10'000 API calls per day allowed for non-commercial use (https://open-meteo.com/en/terms) and on the website I get the error after updating just a handful of times.

Have there been any changes lately that I am not aware of?

[yotkadata]

Just as a short update: It seems I can make exactly one API call from an IP and then I get blocked. I'm not sure about the time period (per day or per hour). When I make the call from a different IP, I get a result, but the call is blocked again.

[patrick-zippenfenig]

Hey, last week I deployed larger changes to support API calls for multiple locations at once. I also adjusted the rate-limiter to take larger queries into account. E.g. If someone retrieves data for 2 locations in one call, the weight is adjusted to 2 calls instead of only one. The same applies for larger amount of weather variables. E.g. 15 weather variables in one call, count as 1.5 calls. Lastly the time duration is factored in. One week was taken as a reference with 2 weeks counting as 2 calls.

As I was primarily designing the rate limiting for weather Forecast API, I was not doing the math for the historical weather API. Data from 1940 until 2022 spans 4'264 weeks and hence the call is adjusted to 4'264 calls worth of data.

That's obviously not useful. I still want to keep the weight adjustment for "heavy" API calls, but the factors need adjustment. Needless to say, if Open-Meteo users would actually fetch 80 years of data with multiple weather variables for 10.000 API calls per day, it will quickly utilise all available server capacity.

The old calculation is

weight = max(1, variables / 10) * max(1, days / 7) * locations

I think If I adjust the weight to

weight = max(variables / 10, variables / 10 * days / 7) * locations

it is better balanced towards API calls with 1 variable and a long time range while for short time-range (1 day), the number of variables is still dominant. For all data from 1940 until 2022 in one go, the weight is 426. Further adjusting the reference time length to 14 days instead of 7 days reduces it to a weight of 213. This seems more reasonable to me given that the size for this response is 12 MB of JSON.

Finally, I want to implement this calculation into the API docs as well, so the API configurator shows the adjusted call weight. There is already a larger update pending to include API calls for multiple locations and individual time-intervals. Researchers often have a list of locations and time-intervals for their trials and the new interface supports such cases.

Wdyt?

[yotkadata]

Thanks Patrick. I wasn't aware of those changes and the way API calls are calculated. I thought one call was every time data is pulled from API, but of course it makes sense to adjust the calculations for limits when multiple locations come into play etc.

With your proposal (14 days), I would be able to make ~46 API calls per day (10.000/213) which would probably be enough given the current amount of traffic. I could also reduce the amount of data by limiting the dates to just the reference period of 30 years and the year that is being compared. That would leave me with ~123 API calls per day. I suppose that is fine.

I'm not sure if it would make sense to apply other rules for the Historical Weather API since it kind of requires larger time series in most cases. But I totally understand the need to limit API calls, so I suppose your proposal is fine.

Thanks for your great work!

[patrick-zippenfenig]

Changes have been deployed to the archive API servers!

Please feel free so also reach out directly in case you need an API key for your application. Because the API is free for everyone, I have limited control to ensure fair use. Some exploit it. It is difficult to find a fair middle-ground. However, projects like your are greatly appreciated and I would be more than happy to support you.

[yotkadata]

Awesome, thanks a lot! I'll probably contact you for the API then.

[rajdevanesan]

I am not sure whether anyone is still looking in to this, I am trying to fetch data from the OpenMateo historical weather API, I am making 60 calls /minute, 600 calls/hour, with 14 days as date-interval, I am always getting HTTP 429. What is the reccomened way, my requirement is to fetch 360 days worth of data for 120,000 locations. Can anyone help?

[rajdevanesan]

params = {
"latitude": lat,
"longitude": lon,
"start_date": current_date.isoformat(),
"end_date": chunk_end.isoformat(),
"daily": [
"temperature_2m_max", "temperature_2m_min", "temperature_2m_mean",
"apparent_temperature_max", "apparent_temperature_min", "apparent_temperature_mean",
"sunrise", "sunset", "daylight_duration", "sunshine_duration",
"precipitation_sum", "rain_sum", "snowfall_sum", "precipitation_hours",
"windspeed_10m_max", "windspeed_10m_mean", "winddirection_10m_dominant",
"shortwave_radiation_sum", "et0_fao_evapotranspiration",
"soil_temperature_0_to_7cm_mean", "soil_moisture_0_to_7cm_mean",
"pressure_msl_mean", "relative_humidity_2m_mean", "cloudcover_mean", "weathercode",
],
"timezone": "UTC",
}

Can I make one call for one whole year? Currently I am making 14days between start_date and end_date.

[chamitro]

Hello to you all, I try to make an application that fetch data from open-meteo for every year until now, for various statistical fact about the weather. You can take a look https://chamitro.github.io/weatherhistoryvault/

But after 2 or 3 times of putting different locations I get the error of API rate limit reached. Do you have any suggestions how can I fix this ?

[SebSwan]

i just take a look on your website. you ask for data from 1940~ to now. It's a huge amount of datas. What is the "API call equivalent" of a request ?

[chamitro]

I think this is the code you request : async function fetchData(lat, lon) { updateProgress(50, "Downloading 85 years of records..."); const historyUrl = ` https://archive-api.open-meteo.com/v1/archive?latitude=${lat}&longitude=${lon}&start_date=1940-01-01&end_date=2024-12-31&daily=temperature_2m_max,temperature_2m_min,temperature_2m_mean&timezone=auto` ; const currentUrl = ` https://api.open-meteo.com/v1/forecast?latitude=${lat}&longitude=${lon}&current_weather=true` ; try { const [hRes, cRes] = await Promise.all([fetch(historyUrl), fetch(currentUrl)]); updateProgress(80, "Processing Climate Data..."); const hData = await hRes.json(); const cData = await cRes.json(); processData(hData, cData.current_weather.temperature); } catch (e) { alert("Weather server busy. Try again."); updateProgress(0, ""); } } But I can give you the whole html file. Can we find a solution? Στις Τετ 24 Δεκ 2025, 3:26 μ.μ. ο χρήστης Setienne ***@***.***> έγραψε:

…

*SebSwan* left a comment (open-meteo/open-meteo#438) <#438 (comment)> i just take a look on your website. you ask for data from 1940~ to now. It's a huge amount of datas. What is the "API call equivalent" of a request ? — Reply to this email directly, view it on GitHub <#438 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIU5U4TGBX3DKAXLXUPGNL34DKIAPAVCNFSM6AAAAACK2KVKCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMOBZG44DOOBTGM> . You are receiving this because you commented.Message ID: ***@***.***>