Visual Crossing is designed to minimize the customer information required to provide weather data services.
For most Weather API use cases, a request contains an API key, a location, a date or date range, and the weather options required by the application. Visual Crossing processes that information to authenticate the request and return the requested weather data.
Some Visual Crossing features intentionally store additional information—for example, when you save a dataset or configuration for later use. Those features are optional and are discussed separately below.
This article explains the main types of customer information that Visual Crossing may process, including:
- Account information
- Payment and billing information
- Weather API keys
- Weather API request data
- Saved datasets and Query Builder configurations
- Information temporarily collected for customer support
For additional information about Visual Crossing’s handling of personal information, see the Visual Crossing Privacy Policy.
Data minimization
A central principle of the Visual Crossing service is to process only the information needed to provide the requested service.
A normal Weather API request does not require you to submit customer names, business records, internal identifiers, or other application data.
In many applications, the only customer-specific information included in a request is:
API key
location
date or date range
request options
If your application uses sensitive locations or dates, you should also consider whether the exact precision supplied to the Weather API is necessary for the weather analysis you are performing.
Later in this article, we’ll discuss ways to reduce the amount of business-specific information included in requests.
Account information
A Visual Crossing account is used to manage access to Weather API services, subscription features, and account settings.
Account information includes information such as the email address associated with the account and authentication credentials.
Passwords are not stored in recoverable plain-text form. Visual Crossing stores password information using a one-way password-hashing process so that the service can authenticate a login without needing to retain the original password.
You should use a unique, strong password for your Visual Crossing account and should never provide your password to another person.
Visual Crossing support personnel will not ask you to disclose your account password.
If you believe your password has been compromised, change it from your account page.
Payment and billing information
Visual Crossing uses Stripe for payment processing for standard online subscriptions.
Where Stripe-hosted or Stripe-embedded payment controls are used, payment-card information is submitted to and processed by Stripe rather than being entered into Visual Crossing application systems.
Visual Crossing may still retain the account, subscription, transaction, and billing information necessary to administer your service.
Customers using invoicing, purchase orders, wire transfers, or other business-to-business payment arrangements may also provide Visual Crossing with business billing information required to administer those arrangements.
For details about information collected through the Visual Crossing website and account services, see the Visual Crossing Privacy Policy.
Your Weather API key
Your Weather API key identifies and authenticates requests made under your Visual Crossing account.
For example:
key=YOUR_API_KEY
The key allows Visual Crossing to determine which account is making a request and which subscription features and limits apply.
An API key should be treated as a credential.
Anyone who obtains your API key may be able to make Weather API requests using your account’s permissions and usage allowance.
Do not publish your API key in:
- Public source-code repositories
- Public documentation
- Public configuration files
- Support forums
- Screenshots
- Client-side applications where the key is expected to remain secret
If you believe an API key has been exposed, replace it immediately.
See How to Find and Manage Your Visual Crossing Weather API Key for instructions.
Changing the API key invalidates the previous key, so applications using the old key must also be updated.
Weather API request data
A typical Timeline Weather API request contains a location and, depending on the request, a date or date range.
For example:
/timeline/38.9697,-77.3850/2026-07-01/2026-07-07
A request may therefore reveal:
- A location of interest
- A date or period of interest
- The weather variables being requested
- An optional identifier or name supplied by the customer
For many applications, this information is not confidential.
For example, a company querying weather for publicly listed retail stores may not consider those locations sensitive.
In other cases, however, the combination of location and date can reveal business information.
Examples might include:
- A potential future facility
- A confidential project location
- An insurance claim location
- Infrastructure or asset locations
- A private research site
- An acquisition target
- A sensitive operational event
Customers should consider the sensitivity of request parameters when designing their integration.
Normal API requests versus stored datasets
It is important to distinguish ordinary Weather API requests from Visual Crossing features that intentionally save a query or dataset.
A normal API request is processed so that Visual Crossing can authenticate the request, determine the requested location and period, generate the weather result, and return it to the caller.
Some optional Visual Crossing services, however, are specifically designed to persist configuration or dataset information.
Examples include saved Query Builder datasets and Stored Dataset functionality.
If you choose to save a dataset, Visual Crossing necessarily retains the information required to reproduce or manage that dataset, which can include:
- Locations
- Date settings
- Weather options
- Dataset configuration
- Identifiers associated with the saved dataset
The Stored Dataset APIs, for example, are specifically designed to view, modify, and execute datasets created using the Query Builder.
If the locations or dates in a request are highly sensitive and you do not want them retained as part of a saved configuration, use the Weather API directly rather than creating a saved dataset.
Protect sensitive locations by reducing precision
Weather data describes atmospheric conditions over an area. In many applications, the Weather API does not need the full geographic precision of an individual building or GPS measurement.
If the exact location is sensitive, you can reduce the precision of latitude and longitude before submitting the request.
For example:
38.969732,-77.385016
could potentially be reduced to:
38.970,-77.385
or, for a less precise request:
38.97,-77.39
As a useful approximation:
| Decimal places | Approximate latitude precision |
|---|---|
| 4 | about 11 m |
| 3 | about 110 m |
| 2 | about 1.1 km |
The actual east-west distance represented by longitude precision varies with latitude.
The appropriate precision depends on your application and the weather information being requested.
For many weather use cases, submitting coordinates to excessive GPS-level precision provides little additional weather value.
Reducing precision can therefore limit how specifically a request identifies a property while still providing weather information representative of the surrounding area.
Coordinates can provide more control than addresses
When location confidentiality matters, latitude and longitude can also provide greater control than submitting a full textual address.
For example, instead of:
123 Example Street, Example City, VA
your application could resolve the location itself and request:
38.970,-77.385
This avoids sending street-address text and allows your application to explicitly control the coordinate precision supplied to Visual Crossing.
Whether this is desirable depends on your application. Textual addresses remain valid Timeline Weather API locations and can be convenient when exact geocoding is required.
Protect sensitive dates
In some applications, the date itself can also contain business information.
For example, querying an exact location for an exact historical date could reveal that an incident, claim, project, or business event occurred there on that date.
If the precise date is sensitive and your application can tolerate a broader query, request a date range and perform the final selection within your own application.
For example, instead of requesting:
2026-07-17
you might retrieve:
2026-07-15/2026-07-20
and select July 17 locally.
This approach is optional and only useful where the date itself is considered sensitive.
Avoid putting sensitive business information in names or identifiers
Some Visual Crossing workflows allow you to associate names or identifiers with locations.
These values are useful when matching returned weather data back to business records.
However, avoid sending meaningful confidential information if a neutral identifier will work just as well.
For example, instead of:
ProposedAcquisition_Target_A
use:
location_001
or another internal opaque identifier.
Your application can maintain the relationship between that identifier and the underlying business record.
This principle applies generally to API integrations: do not transmit descriptive business information when a non-sensitive identifier is sufficient.
HTTPS protects Weather API requests in transit
Visual Crossing Weather API endpoints use HTTPS.
HTTPS encrypts the communication between your application and the Visual Crossing service while it travels across the network.
Applications should always use the HTTPS Weather API endpoints and should keep normal TLS certificate verification enabled.
Do not disable certificate verification in an HTTP client merely to work around local certificate, proxy, or trust-store problems.
If an HTTPS connection fails, correct the client, operating-system, corporate-proxy, or certificate configuration causing the failure.
Customer-support diagnostics
When troubleshooting a technical issue, the Visual Crossing Support Team may need additional information about a failing request.
In some cases, support may ask for permission to enable additional diagnostic logging associated with your account so that a specific issue can be investigated.
Where account-specific request tracing requires customer authorization, it should only be enabled with that authorization and for the purpose of resolving the support case.
If request locations, dates, or other query values are sensitive, tell the Support Team before diagnostic logging is enabled.
You can also provide a sanitized or representative request where that is sufficient to reproduce the problem.
For guidance on creating an effective technical-support request, see Helping Us Help You: How to Submit an Actionable Technical Support Case.
Browser applications require additional API-key consideration
A Weather API key included in browser-side JavaScript can normally be viewed by a user through the browser’s developer tools or network inspector.
For example, a browser request containing:
fetch(
"https://weather.visualcrossing.com/..." +
"?key=YOUR_API_KEY"
)
does not make the key secret merely because it appears inside JavaScript.
If your application requires the API key to remain private, make the Weather API request from a server-side component that you control and return only the necessary result to the browser.
The appropriate architecture depends on your application and subscription requirements.
Limit the data you send
When designing a Weather API integration, ask whether every value being sent is actually required.
For a sensitive application, useful practices can include:
- Prefer an opaque internal identifier to a descriptive business name.
- Submit only the coordinate precision needed by the weather use case.
- Avoid sending a street address if a less-specific coordinate is sufficient.
- Avoid saved Query Builder datasets when the location configuration should not be retained.
- Use broader date ranges if the exact date itself is confidential and a range is practical.
- Keep API keys out of public repositories and client applications where secrecy is required.
- Tell Visual Crossing Support when request information involved in troubleshooting is confidential.
These choices can reduce the amount of business-specific information exposed to any external service.
Visual Crossing infrastructure and service providers
Visual Crossing uses established cloud and payment-service providers as part of delivering its services.
Production weather services use Amazon Web Services infrastructure, while Stripe is used for standard online payment processing.
The use of specialist service providers allows infrastructure and payment functions to be handled by systems designed specifically for those purposes.
The Visual Crossing Privacy Policy provides additional information about the company’s collection and handling of information through its website and services.
What information should I consider confidential?
Only you can determine what information is confidential within your organization.
When conducting a security or privacy review, consider whether the following could reveal sensitive business information:
| Information | Possible concern |
|---|---|
| API key | Allows use of your Weather API account |
| Exact coordinates | May identify a property, asset, or project |
| Street address | Can explicitly identify a site |
| Exact historical date | May identify an incident or business event |
| Location name | May reveal an internal project or customer |
| Saved dataset | Persists the configured locations and query options |
| Support diagnostics | May contain request information needed for troubleshooting |
For many customers, none of the weather locations or dates they query are confidential.
For organizations where they are sensitive, the techniques described in this article can help minimize the information transmitted or intentionally stored.
Questions about data protection
Security and privacy requirements vary by organization and use case.
If you are conducting a security, privacy, procurement, or enterprise review and need information beyond this article, contact Visual Crossing with your specific requirements.
For general technical and account questions, use Visual Crossing Support.
For privacy-related questions, see the Visual Crossing Privacy Policy and the contact information provided there.
Summary
Visual Crossing is designed so that a normal Weather API integration requires relatively little customer-specific information.
A typical request contains:
API key
location
date or date range
weather request options
Customers with sensitive locations or dates can further minimize the information sent by reducing coordinate precision, using neutral identifiers, avoiding unnecessary address details, and selecting direct API requests instead of intentionally saved datasets where appropriate.
Some optional services—such as saved Query Builder or Stored Dataset workflows—necessarily retain the configuration required to provide those features.
API keys should be treated as credentials, and applications should always use HTTPS with normal certificate verification.
For more information about personal-information handling, see the Visual Crossing Privacy Policy.
