Timeline Low Latency LLX Weather API

The Timeline Low Latency eXecution Weather API is a highly scalable, lightweight endpoint designed for applications that require extremely fast responses and high request volumes, such as IoT devices, mobile apps, and embedded systems. It provides current conditions, daily and hourly forecasts up to 15 days, minutely data (where available), and weather alerts.

Timeline LLX is built on the same data engine as the full Timeline Weather API. Most parameter names are identical, making migration easy. LLX focuses on speed and efficiency, while the full Timeline API provides advanced features such as long-range forecasts, deep historical data, climate statistics, aggregations, and batch queries.

Timeline LLX is optimized for ultra-low latency performance, with typical response times below 40 ms—even under high concurrency. This makes it well-suited for real-time consumer apps, vehicle and fleet telematics, IoT devices, and any application requiring immediate weather results at scale.

In typical industry benchmarks, many weather APIs respond in 150–600 ms. Timeline LLX is engineered to answer in < 40 ms, delivering results up to 5–10× faster than traditional weather endpoints.

The Timeline LLX endpoint is currently beta and minor changes may occur. Please contact technical support for more information.

Why would I choose Timeline LLX instead of Timeline?

The Timeline Weather and Timeline LLX Weather API are complementary APIs built around the Visual Crossing Weather Data Engine and models. The Timeline LLX endpoint is designed primarily for extremely fast, high-volume applications such as IoT devices, mobile apps, or embedded systems. If you require large historical datasets, long-range forecasts, custom aggregations, almanac data, statistical data, climate normals, or deep history, the full Timeline API may be a better choice.

Most parameters shared are identical to Timeline API to help migration between the APIs as necessary.

When to use Timeline LLX vs Timeline

Feature / NeedUse LLXUse Timeline
Ultra-fast responses, low bandwidth
High concurrency or IoT devices
Simple current + 15-day forecast
Output formatsFlat JSON, CSVFlat JSON, Hierarchical JSON, CSV
Hourly history since 1970
Long-range forecast beyond 15 days
Climate normals, stats, energetics
Multi-location / batch queries
Aggregation (daily, weekly, monthly)
Full location parsing✔ (basic)✔ (advanced)

How to make Requests in the Timeline LLX Weather API

Quick Parameter Reference

ParameterRequiredExampleDescription
keyYeskey=YOUR_API_KEYYour API key
latitude, longitudeUsuallylatitude=40.7&longitude=-74.0Preferred location input
cityOptionalcity=London&country=gbGeonames lookup
postalCodeOptionalpostalCode=20170, country=usPostal lookup
datestart, dateendOptionaldatestart=yesterday&dateend=tomorrowRequested date range
contentTypeOptionalcsv or flatjsonResponse format
includeOptionaldays,hours,alertsLimit output content
elementsOptionaladd:snowdepthModify element list

Timeline LLX Request format

The simplest form of the Timeline LLX request includes your API key plus the latitude and longitude of the requested location.

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&latitude=51.510&longitude=-0.118 

Our free plan includes an API key for development and limited use, including commercial applications. Sign up here.

By default, the response includes:

  • current conditions
  • 7-day daily forecast
  • 48 hours of hourly forecast
  • active weather alerts

The response is returned in JSON format using the Visual Crossing Flat JSON response format to minimize the amount of data transferred.

{
  "days": {
    "datetime": [
      "2025-11-07",
      "2025-11-08",
      "2025-11-09",
      "2025-11-10",
      "2025-11-11",
      "2025-11-12",
      "2025-11-13",
      "2025-11-14"
    ],
    "tempmax": [16, 14, 14, 14, 14, 15, 16, 17],
    "tempmin": [13, 8, 6, 11, 9, 11, 12, 13],
    "temp": [14, 12, 10, 12, 12, 13, 14, 15],
...
}

The standard query requests data for today plus the next seven days (8 days total) and includes the daily forecast for the full seven day period, the hourly forecast for the first two days of the request, the current conditions for the requested location. If alerts have been issued for the location, they will also be present.

Extending the date range

The Timeline LLX endpoint permits weather data requests from three days in the past up to 15 days in the future. Date ranges are specified using the datestart and dateend parameters and support both fixed dates such as 2025-10-01 and dynamic dates such as ‘yesterday’ and ‘tomorrow’. For example the following requests data for yesterday, today and tomorrow.

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&latitude=51.510&longitude=-0.118&datestart=yesterday&dateend=tomorrow

If a request exceeds the supported date boundaries, the API returns a 400 BAD_REQUEST response with an explanation of the invalid range.

Changing the response format

You may use the contentType parameter to modify the response from flatjson to csv. When doing this, you also must add the ‘include’ parameter to indicate which data section you require (days, hours, minutes or alerts).

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&latitude=51.510&longitude=-0.118&contentType=csv&include=days

Specifying the location

We recommend passing the latitude and longitude as the location. This provides the absolute fastest response from the API and provides you with the exact knowledge of the requested location. The API also provides the ability to specify a location by other information such as country, city, postal or zip code and various administrative areas. We use the Geonames geographical database as a source. This ensures standardized, globally consistent location matching.

Requesting a location by latitude and longitude

When requesting the location by latitude and longitude, the API requires that latitude is specified as a decimal number from -90 (the South Pole) to 90 (the North Pole). The longitude is a decimal number from -180 to 180 with zero through the zero meridian at London, United Kingdom.

Requesting a location by city name

To request a location by city name, the ‘city’ parameter can be used:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&city=London&country=gb&include=info,days

In this case the city name and country code has been included. You should always include a country code. We recommend specifying this using the official ISO 2 character code. Including a standard country code in your request prevents the common confusion that occurs due to many city names and administrative names containing duplicates across countries. In some cases, including the city name and country is not sufficient to uniquely identify a location. In that case an administrative location can be includes.

In the United States, administrative level one corresponds to state level administrative locations. Therefore we can distinguish between ‘Leesburg, Virginia’ and ‘Leesburg, Florida’

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&city=leesburg&admin1=va&country=us&include=info,days

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&city=leesburg&admin1=fl&country=us&include=info,days

Requesting a location by state, county or other administrative name

You can search by administrative level one and two alone. Level one is typically equivalent to federal states and level two includes counties etc. The latitude and longitude returned will correspond to a calculated centroid of that admin area. If only a country is specified, we attempt to include the latitude and longitude if the capital city.

Requesting a location by ZIP code or postal code

We currently offer postal code level support for the USA, the United Kingdom and Germany. We plan to extend this based off user feedback. Postal codes can be requested using the postalCode parameter. Again, the country code is required:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&postalCode=20170&country=us&include=info,days

Postal and ZIP codes must be passed as text strings. For US ZIPs with leading zeros (e.g., 01002), ensure your client code does not drop the leading zero.

Additional Parameters

Modifying the weather elements

The standard query includes the most commonly use weather elements. If you would like to include additional elements, or remove unused ones, you can use the elements parameter in the same way as the Timeline Weather API.

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&latitude=51.510&longitude=-0.118&include=info,days&elements=add:snowdepth

The add:snowdepth adds the snowdepth element to the standard list of elements. You can also use the remove: prefix to remove items from the standard list. If you specify elements without the prefix, the default element list will not be used and only the specified elements will be included in the response.

Specifying metric, us and uk units

The unit group parameter can be added to switch the units of the request:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&postalCode=20170&country=us&unitGroup=metric

metric → °C, mm, m/s
us (default) → °F, inches, mph
uk → °C, mph, mm

Other parameters

The Timeline LLX Weather API supports many of the parameters used by the Timeline Weather API including the lang parameter for choosing the output language, the options parameter for changing advanced queries options.

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx?key=YOUR_API_KEY&latitude=51.510&longitude=-0.118&lang=de
&options=nonulls

Passing Parameters as POST Form Data or JSON Body

In addition to sending parameters as URL query string arguments, the Timeline LLX Weather API also supports HTTP POST requests. This can be useful when:

  • Your request contains many parameters
  • You want to avoid exposing the full request URL
  • Your client framework prefers POST with form encoding or JSON

The following POST formats are supported:

Passing Parameters as POST Form Fields (application/x-www-form-urlencoded)

Send parameters exactly as you would in the query string, but place them in the POST request body:

Example – cURL

curl -X POST \
  "https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "key=YOUR_API_KEY" \
  -d "latitude=51.510" \
  -d "longitude=-0.118" \
  -d "include=info,days"

Example – JavaScript (fetch)

fetch("https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx", {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
key: "YOUR_API_KEY",
latitude: "51.510",
longitude: "-0.118",
include: "info,days"
})
}).then(res => res.json())
.then(data => console.log(data));

Passing Parameters as a JSON POST Body (application/json)

You may also send parameters inside a JSON object. The field names are identical to the URL parameters.

Example – cURL (JSON body)

curl -X POST \
  "https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "YOUR_API_KEY",
    "latitude": 51.510,
    "longitude": -0.118,
    "include": "info,days"
  }'

Example – JavaScript (fetch)

fetch("https://weather.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/timelinellx", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    key: "YOUR_API_KEY",
    latitude: 51.510,
    longitude: -0.118,
    include: "info,days"
  })
}).then(res => res.json())
  .then(data => console.log(data));

Response Format

Whether you POST or GET, the server returns the same flat-JSON response (or CSV if you set contentType=csv).

HTTP Response Code and Error Handling

The API communicates error codes through the HTTP response code. In addition, the body the response will normally include additional error information indicating the cause of the error. The possible HTTP response status codes include:

200 OK – a successfully processed request

400 BAD_REQUEST – The format of the API is incorrect or an invalid parameter or combination of parameters was supplied

401 UNAUTHORIZED – There is a problem with the API key, account or subscription. May also be returned if a feature is requested for which the account does not have access to.

404 NOT_FOUND – The request cannot be matched to any valid API request endpoint structure.

429 TOO_MANY_REQUESTS – The account has exceeded their assigned limits. See What is the cause of “Maximum concurrent jobs has been exceeded”, HTTP response 429

500 INTERNAL_SERVER_ERROR – A general error has occurred processing the request.

For general information on debugging API queries, please see: How to debug problems when running weather API queries in code

Questions or need help?

If you have additional questions, please post on our actively monitored forum for the fastest replies. You can also contact us via our support site