Upcoming Breaking Changes - July 2023
We're changing the daily timestep in the following endpoints:
- /v4/weather/forecast
- /v4/weather/realtime
- /v4/weather/history/recent
Until today the daily timestep returned the values from 12AM UTC to 12AM UTC.
We're changing it to align with our /v4/timeline endpoint:
the new daily timestep will provide 6AM-6AM based on the timezone of the location in the query
Upcoming Breaking Changes - August, 2022
We will be changing the functionality of certain data fields in the Historical API
While no errors should be raised as part of the release process, users should schedule changes to be deployed after August 29th, 2022.
Please see more information below:
Data Field Updates - Historical API
To get ahead of the planned updates, users need to change the following field names and schedule the changes for deployment after August 29 to ensure continuity of historical data usage.
totalPrecipitationAccumulation
Replace totalPrecipitationAccumulation with precipitationAccumulation which aggregates precipitation accumulation hourly.
For daily sum, use precipitationAccumulationSum.
et0
Instead of et0, use potentialEvaporation, which will change to hourly aggregation (currently daily sum).
For daily aggregation, please use potentialEvaporationSum.
snowAccumulation and totalSnowAccumulationLwe
Instead of snowAccumulation and totalSnowAccumulationLwe, use snowAccumulationLiquidWaterEquivalent.
For daily sum, use snowAccumulationLiquidWaterEquivalentSum.
evaporationFromVegetationTranspiration
Replace evaporationFromVegetationTranspiration with evaporationVegetationTranspiration, which aggregates hourly evaporation data.
For daily sum, use evaporationVegetationTranspirationSum.
Please note if customers do not make these adjustments totalPrecipitationAccumulation, et0, totalSnowAccumulationLwe, snowAccumulation, and evaporationFromVegetationTranspiration data fields will not return the expected daily sum for the last 100 days of historical data.
Further, potentialEvaporation MAX aggregation potentialEvaporationMAX will return the hourly maximum instead of the daily sum.
Gradually, by the end of the year, and according to customers' usage, the below fields will be removed from the API:
totalPrecipitationAccumulation
et0
totalSnowAccumulationLwe
snowAccumulation
evaporationFromVegetationTranspiration
We will communicate with you ahead of hard deprecation dates.
Upcoming Breaking Changes - June, 2022
On September 1st, 2022, Historical API will no longer support et0 data field.
Upcoming Breaking Changes - May, 2022
On September 1st, 2022, Timeline API GET requests will no longer support the following query parameter formats:
fields[]=value1&fields[]=value2
The only supported and recommended to use format for GET requests is comma-separated values like fields=value1,value2,...,
Event's "Location" in Webhook Payload - Effective July 1st, 2021
What’s changing?
The webhook payload for alerts is going under the change to only support locations object (plural, each child consisting of an id), versus the outdated location attribute.
{
"data": {
"alert": ...alert,
"insight": ...insight,
"locations": [ // introduced
{ "id": "38f689d83c264eb0b084ba39975f3413" },
],
"location": ...location, // deprecated
"notification": ...notification,
"event": ...event
}
}
Why are you making this change?
As part of our release of alerts based on insight categories (reporting severe weather events issued by national authorities), we have extended the notification payload sent to your webhook to support multiple locations. This is needed to de-dup notifications for a singular weather event, thereby reducing alert fatigue in developer's applications.
When is this going to happen?
Effective immediately, all payloads will consist of both location and locations objects throughout the deprecation period. On July 1st, the deprecation date, the location object will be redacted.
What will happen if I do nothing?
Until the above-mentioned date, apps developed on top of our alerting system will continue to work without change. Afterward, ones relying on that object, to avoid any business disruption on your end make sure to migrate your code to use the new object structure.
Note that this is true to any alert notification type, regardless if they are triggered by a custom insight (with tailored conditions) or by any of the events residing under an insight category.
What are the alternatives?
As said, the only alternative to the previous functionality of the location object is to use the first object of the locations array.
For any issues or questions, please contact our support at [email protected].