Customers of the Visual Crossing Weather API may keep weather data results and use them again inside their own application. There are two permitted ways to do that, and they are not interchangeable. Storage keeps an application record for the long term. Caching keeps a temporary copy so the application can reuse operational weather without making another request. The freshness limits below apply to the cache, and to recent history that may still be revised. They do not apply to an older historical record, or to an archived forecast kept for reference.
This guide should be read with the Visual Crossing Weather License Terms. If a signed agreement says something different, the signed agreement controls.
The Rule
You may store Visual Crossing results long term, and you may cache them short term, then use either again inside your application. Storage keeps application records long term. Caching keeps operational weather temporarily so the application can reuse it without another request. In either case, the weather has to support a feature of your application that is not itself a weather-data service. You may not offer the results as a generic weather data product, download service, API, or bulk dataset.
Two uses are covered, and they map to the two patterns above.
- Historical efficiency. Store historical results that form part of your application’s records so they do not need to be requested again.
- Application use. Keep a result and show it later to a user of your app, including the raw fields, when that display supports a non-weather feature of the app.
Both apply to observations, historical records, current conditions, forecasts, alerts, and the other fields the service returns. What changes is why you keep the result, and whether you are still presenting it as current.
Storage and caching are different
Storage is the long-term copy. It keeps the weather that belonged to an event, job, site, or analysis, and it stays with that record. History is the usual case: the conditions on a logged hike, hunt, bike ride, claim, or job. An archived forecast is also storage when you keep the forecast that was issued, so you can refer to it or compare it later. That saved forecast is a record of what was forecast at the time. It is not a live forecast, and it should not be shown as one.
Caching is the short-term copy. It exists so the application can answer again without calling the Weather API. A cached forecast, current condition, or alert is operational data, so it has a lifetime. When that lifetime ends, refresh it before showing it as current.
| Storage | Caching | |
|---|---|---|
| Purpose | Keep an application record. | Reuse operational weather without another request. |
| Typical data | History. Sometimes an archived forecast kept for reference or analysis. | Current conditions, alerts, and the forecast the user is about to act on. |
| Lifetime | No operational expiry for older history. Recent history may still be revised, so refresh it if the exact value matters. | Short. See the cache limits below. |
| How it is shown | As what the weather was, or what the forecast said when it was saved. | As current or upcoming weather, until the cache expires. |
| Allowed | Yes, when it supports a non-weather feature of the application. | Yes, in that same application context, and only within the cache lifetime. |
An activity log that still shows the temperature on a hike from last November is storage. A home screen that shows tomorrow’s forecast is a cache, and that forecast should be no more than 6 hours old. The same application can do both.
What “in the context of the application” means
The weather has to support a feature of your product that is not a weather-data service. A user should reach it by using your app, not by asking your service for weather. Simply requiring a login does not make a standalone weather-data service an application use.
- The data is tied to something your app already does: an activity, claim, job, site, route, asset, account, or report.
- The user is a user of that application, not a caller of a weather endpoint who happens to be signed in.
- You control the display. A table, chart, or detail panel inside the app is fine. A public file, open API, or bulk export of the same rows is not.
- You may keep a short-term cache after the original request so the screen loads again without a new Weather API call, subject to the lifetimes below.
Raw weather data means observations, forecasts, historical records, alerts, or other weather fields in substantially the same form Visual Crossing returned. A derived result is something you build from those fields, such as a score, alert, summary, or recommendation. Both may be kept. Raw fields stay inside the application, and only in support of a non-weather feature. Derived results may also appear in reports and other customer-facing outputs, provided they are not a substitute weather feed.
Time to Live (TTL)
Time to live, or TTL, is the maximum time a saved result may be treated as current before it should be refreshed. A TTL is measured from the time your application received the result from the Weather API. When the TTL expires, query again before showing that field as current, operational, or final.
We use TTL in this guide, and we expect to use the same term in the license terms and in other customer documents. A stored older record does not have an operational TTL. A cache of operational weather does. Recent history sits between the two, because the underlying observations can still change.
Scenarios
The test is the same in each case: is the weather supporting the application, or is the application a way to get weather data?
| Scenario | What the customer does | Result |
|---|---|---|
| Activity log | Store the conditions for a hike, hunt, bike ride, or other logged activity, and show that history when the user opens the entry. | Allowed. The weather is part of the user’s record in your app. |
| Claims or inspection app | Save the observed weather for an address and date, then show it again on the claim, job, or report. Refresh recent history if the exact value matters. | Allowed. Re-serving the saved result keeps the record stable, once the observation has settled. |
| Agriculture or construction schedule | Cache the working forecast for a site and refresh it within 6 hours. Separately, store the forecast that was used for a past decision if you need it for reference. | Allowed. The live forecast is a cache. The saved forecast is storage. |
| Logistics or retail dashboard | Keep conditions for your locations and show them to signed-in users of that dashboard, as part of the operational view. | Allowed, if the data supports that application and is not offered as a standalone weather feed. A login by itself is not enough. |
| Efficiency cache | Keep a recent operational result so the next view of the same location does not call the API again. | Allowed. This is caching, so forecast, current, and alert copies still expire. |
| Derived score or alert | Turn weather fields into a risk score, delay flag, or recommendation and show that output. | Allowed. Derived results may also be used more broadly than raw fields, provided they are not a substitute data feed. |
| Generic weather download site | Let anyone pick a place and date and download CSV, JSON, or an API response of Visual Crossing data. | Not allowed. That is a competing weather data service, even if the user has to sign in. |
| White-label weather API | Re-expose Visual Crossing results through your own API, marketplace, or bulk file for other developers. | Not allowed, unless Visual Crossing has agreed to that use in writing. |
| Public bulk export | Publish a page, endpoint, or file where raw records can be scraped, exported, or retrieved in bulk outside your app. | Not allowed. In-app display is not the same as a public download service. |
An activity logging example
An activity app may request the weather for a location, date, and time, store that result with the logged hike, hunt, bike ride, or other activity, and show it again when the user opens the entry months later. That is storage. The app may also cache a forecast for activities planned this week and show that forecast in the app. That is caching, and the cached forecast should be refreshed before it is 6 hours old.
Both are allowed because the weather explains the activity. Neither is allowed if the same app, or a side endpoint, lets a visitor download weather history or forecasts for any location as a data product. Requiring an account does not change that.
Cache lifetime, not storage lifetime
These advisory limits should be applied to short-term caching of operational data. They do not apply to long-term storage of older history, or to an archived forecast kept as a record of what was forecast. Recent history has its own refresh guidance, because that record can still change.
A cache is allowed. A stale operational display is not. If your application shows a forecast, a current condition, or an alert from cache, refresh it before these limits.
- Do not provide forecasts that are more than 6 hours out of date.
- Do not provide current conditions that are more than 30 minutes out of date.
- Do not provide alerts that are more than 15 minutes out of date.
Out of date means the age of the cached result, measured from the time your application received it. If the cache is older than the limit, query again before showing that field as current. An archived forecast is not subject to the 6-hour limit if it is labeled as the forecast saved at that time, and is not presented as the current forecast.
Recent history can still change
Historical observations are not fixed the moment the day ends. Station reports arrive on different schedules, and later quality-control checks can revise a value. For many locations, the first observations are generally in place after about three days. Quality checks and late transmissions can still modify a record in the weeks after that. After about two to three months, the data usually does not change in a material way, though a provider correction can still flow through.
The details are in How historical weather data is updated. If your application shows recent history as the weather that occurred, refresh it on the schedule below rather than treating the first response as final.
Recommended TTL
These are the recommended maximum times to serve a result without a refresh. A shorter TTL is fine. Older stored history, and an archived forecast kept for reference, have no operational maximum.
| Data | Recommended TTL | Do not |
|---|---|---|
| Alerts | 15 minutes | Do not provide alerts more than 15 minutes out of date. |
| Current conditions | 30 minutes | Do not provide current conditions more than 30 minutes out of date. |
| Forecast | 6 hours | Do not provide forecasts more than 6 hours out of date. |
| Recent history, same day through 3 days | 24 hours | Do not treat a same-day or previous-day observation as final. Late station reports are still arriving. Refresh at least daily if the value is shown as the record of what happened. |
| Recent history, 3 days through 60 days | Refresh before a decision | Do not rely on a stored value from this window for a claim, report, or other exact-value use without a fresh query. Quality control can still revise it. See how historical weather data is updated. |
| Older stored history | No operational TTL | Long-term storage is appropriate. Do not apply the operational cache limits. A provider correction is still possible, so refresh if a later dispute turns on the exact value. |
| Archived forecast | No operational TTL | Allowed as storage for reference or analysis. Label it as the forecast saved at that time. Do not present it as the current forecast. |
Show the observation or forecast time next to cached operational data when the screen could be read as live. An activity log from last season is storage and does not need a 15-minute refresh. A storm alert on the home screen is a cache and does. Yesterday’s rainfall on a claim screen is recent history: keep it with the record, and refresh it if the exact amount still matters.
What is still not allowed
Section 13 of the license terms still applies. You may not use the service or its results to create, operate, or offer a weather data API, bulk weather dataset, weather data marketplace, or similar service that competes with Visual Crossing.
- A site or app whose purpose is to look up and download weather for arbitrary places and dates.
- Your own weather API, webhook, or file drop that returns Visual Crossing fields to other developers or customers as data.
- A public archive, map tile set, or spreadsheet library of raw Visual Crossing results.
- Sharing raw results with a subsidiary, separate division, or consulting firm unless Visual Crossing has agreed.
Paid customers may use the data as an input to their own application, dashboard, alert, model, or business process. That permission does not include resale of the raw feed. Putting the same feed behind a login does not turn it into an application use.
How to tell the difference?
- Would the feature still make sense if the weather fields were removed? If the product is the weather file, it is not in scope.
- Can someone outside the application retrieve the raw rows by URL, API key, export, or scrape? If yes, close that path.
- Are you keeping a record, or showing operational weather? A record is storage. Operational weather is a cache and expires.
- If you removed the login, would this be a weather lookup service? If yes, the login is not enough to make it an application use.
Practical notes
- Storage and caching are both allowed. Storage keeps the application record. Caching keeps a temporary operational copy.
- A stored forecast is not a current forecast. Label the time it was saved if a user could confuse the two.
- Caching does not change how records are counted on the request that created them. It can reduce later requests. A refresh of recent history is a new request.
- Attribution still applies on plans that require it. If your plan requires it, display the attribution near the data or derived information and link it to Visual Crossing. See how to attribute Visual Crossing weather data.
- Pass through the weather-data disclaimer in a form that fits your product, as required by the license terms.
- Fair use still applies to how you query the Weather API. A cache should reduce repeat calls, not hide a bulk extraction.
- If a use is close to a data product, write to us through the support portal with the user flow before you launch it.
Visual Crossing Corporation · Visual Crossing Weather API