/flightsFuture now covers every date from tomorrow through 12 months.
Table of Contents
TL;DR
- /flightsFuture now returns confirmed scheduled flights for the next 7 days. Those dates used to come back empty.
- Future flight coverage now runs unbroken from the following day through 12 months ahead, from one endpoint.
- Same API key, same response format, same rate limits. Nothing breaks and you don’t need to update your code.
- Included on Starter, Professional, and Enterprise plans.
As of September 1, /flightsFuture returns confirmed scheduled flights for any date from the following day through twelve months out. The seven days immediately after the current date used to return nothing. This was also the most requested addition to our flight data that we are happy to announce is now live.
This post covers how the coverage fits together now, what the calls look like, and where the edges are.
How coverage fits together now
Aviationstack serves flight data through three endpoints, each covering a different slice of time. Every window below is relative to the date of the request.
/flights is the live feed. It returns real-time status for flights on the current date, and it also serves historical flights for past dates. This is the endpoint behind trackers, status boards, and delay alerts
curl "https://api.aviationstack.com/v1/flights" \
-d access_key=YOUR_ACCESS_KEY \
-d dep_iata=DEL \
-d flight_iata=AI2951 \
-G
{
"pagination": {
"limit": 100,
"offset": 0,
"count": 1,
"total": 1669022
},
"data": [
{
"flight_date": "2019-12-12",
"flight_status": "active",
"departure": {
"airport": "San Francisco International",
"timezone": "America/Los_Angeles",
"iata": "SFO",
"icao": "KSFO",
"terminal": "2",
"gate": "D11",
"delay": 13,
"scheduled": "2019-12-12T04:20:00+00:00",
"estimated": "2019-12-12T04:20:00+00:00",
"actual": "2019-12-12T04:20:13+00:00",
"estimated_runway": "2019-12-12T04:20:13+00:00",
"actual_runway": "2019-12-12T04:20:13+00:00"
},
"arrival": {
"airport": "Dallas/Fort Worth International",
"timezone": "America/Chicago",
"iata": "DFW",
"icao": "KDFW",
"terminal": "A",
"gate": "A22",
"baggage": "A17",
"delay": 0,
"scheduled": "2019-12-12T04:20:00+00:00",
"estimated": "2019-12-12T04:20:00+00:00"
},
"airline": {
"name": "American Airlines",
"iata": "AA",
"icao": "AAL"
},
"flight": {
"number": "1004",
"iata": "AA1004",
"icao": "AAL1004"
},
"aircraft": {
"registration": "N160AN",
"iata": "A321",
"icao": "A321",
"icao24": "A0F1BB"
},
"live": {
"updated": "2019-12-12T10:00:00+00:00",
"latitude": 36.2856,
"longitude": -106.807,
"altitude": 8846.82,
"direction": 114.34,
"speed_horizontal": 894.348,
"speed_vertical": 1.188,
"is_ground": false
}
}
]
}
/timetable returns the real-time schedule for a single airport on the current date. You pass an airport iataCode and a type of departure or arrival, and get back that side of the board. There’s no date parameter; it’s always the current day.
curl "https://api.aviationstack.com/v1/timetable" \
-d access_key=YOUR_ACCESS_KEY \
-d iataCode=DEL \
-d type=departure \
-d flight_iata=AI2951 \
-G
{
"data": [
{
"airline": {
"iataCode": "AV",
"icaoCode": "AVA",
"name": "SA AVIANCA"
},
"arrival": {
"delay": "65",
"estimatedTime": "2024-06-18T23:10:00.000",
"gate": "3",
"iataCode": "JFK",
"icaoCode": "KJFK",
"scheduledTime": "2024-06-18T22:05:00.000",
"terminal": "1"
},
"departure": {
"actualRunway": "2024-06-18T20:46:00.000",
"actualTime": "2024-06-18T20:46:00.000",
"delay": "97",
"estimatedRunway": "2024-06-18T20:46:00.000",
"estimatedTime": "2024-06-18T19:10:00.000",
"gate": "C4",
"iataCode": "TPE",
"icaoCode": "RCTP",
"scheduledTime": "2024-06-18T19:10:00.000",
"terminal": "2"
},
"flight": {
"iataNumber": "AV4511",
"icaoNumber": "AVA4511",
"number": "4511"
},
"status": "scheduled",
"type": "arrival"
}
]
}
/flightsFuture returns confirmed scheduled flights for a future date. Before this release its range started at seven days out. Now it starts at the following day and runs through twelve months ahead.
curl "https://api.aviationstack.com/v1/flightsFuture" \
-d access_key=YOUR_ACCESS_KEY \
-d iataCode=DEL \
-d type=departure \
-d date=2027-08-19 \
-G
{
"data": [
{
"weekday": "4",
"departure": {
"iataCode": "BER",
"icaoCode": "EDDB",
"terminal": "1",
"gate": "B17",
"scheduledTime": "2027-08-19 06:15:00"
},
"arrival": {
"iataCode": "CDG",
"icaoCode": "LFPG",
"terminal": "2F",
"gate": "",
"scheduledTime": "2027-08-19 08:05:00"
},
"aircraft": {
"modelCode": "BCS3",
"modelText": "Airbus A220-300"
},
"airline": {
"name": "",
"iataCode": "AM",
"icaoCode": "AM"
},
"flight": {
"number": "5748",
"iataNumber": "AM5748",
"icaoNumber": "AM5748"
}
}
]
}
One thing worth knowing if you combine these:
The three endpoints don’t share a schema.
/flights uses iata and icao keys with full ISO timestamps.
/timetable and /flightsFuture use iataCode and icaoCode. /timetable items carry a status (scheduled, active, landed, cancelled, and so on) and a type echoing the side of the board you asked for.
Timestamps differ as well. /flights uses ISO 8601 with a timezone offset (2019-12-12T04:20:00+00:00), /timetable uses ISO with milliseconds and no offset (2024-06-18T22:05:00.000), and /flightsFuture uses a space-separated local time (2027-08-19 06:15:00) alongside a weekday field where Monday is 1. If you’re building one view across them, normalize before you merge.
The practical rule: a past date or the current date, use /flights. The current date’s full board for an airport, use /timetable. The following day onward, use /flightsFuture. There’s no longer a window where the answer is “none of them.”
What this unblocks
The six-day gap was small on a calendar, but larger in practice, because it sat exactly where planning happens. A few things that get simpler now:
Itinerary and booking views. A user searching for flights on Thursday gets a confirmed schedule from the same call that handles next month. You no longer need a second data source or a “check back later” state for near-term dates.
Freight and cargo planning. Logistics tools can see the full week of scheduled cargo flights ahead instead of only the current day’s departures, which is the window most routing decisions are made in.
Multi-day trip views. Corporate travel and expense tools can assemble a five-day trip from one endpoint rather than combining the current day’s board with next week’s schedule and guessing at the days between.
AI agents. “What flights are available Thursday?” is one of the most common questions a travel agent gets asked and one of the hardest to answer from an API that only knows the current date and next month. An agent wired to Aviationstack can now answer it for any day in the coming week with a single call.
Getting started
Nothing changes about how you call the endpoint. Same path, same authentication, same parameters. The only difference is that a date inside the next seven days now returns results.
A request for departures from Berlin four days out:
curl "https://api.aviationstack.com/v1/flightsFuture" \
-d access_key=YOUR_ACCESS_KEY \
-d iataCode=BER \
-d type=departure \
-d date=2026-09-21 \
-G
Swap type=departure for type=arrival to get inbound flights. The date parameter accepts any day from the following day through twelve months ahead.
The response uses the /flightsFuture structure shown above. If you already parse those responses, your existing code handles this. The fields, types, and nesting are identical for a flight next week and a flight in March.
Full parameter and response field reference is in the documentation.
Limits and what to expect
The newly added dates are served through the same response schema and the same authentication as the rest of /flightsFuture, which runs up to 12 months out. Response times and rate limits are unchanged on every plan.
Those rate limits are worth knowing before you build. /flightsFuture and /timetable both allow one request every 10 seconds on paid plans. Each /flightsFuture call covers one date, so a full week for one airport is seven calls spaced over about a minute. If you’re rendering a week view, fetch the days on a schedule and cache the results rather than calling on page load. Confirmed schedules for a date several days out don’t change often enough to justify refetching them per request.
Coverage for very small regional airports can vary slightly in the near-term window. This is consistent with how /flightsFuture behaves across its full range and isn’t specific to the new dates. Major and mid-size airports are unaffected.
/flightsFuture is a paid-plan endpoint, and that hasn’t changed. The expanded range is included on Starter, Professional, and Enterprise at no additional cost.
FAQ
Do I need to change my integration?
No. Existing API keys work as-is, the response structure is identical, and nothing is deprecated. If you already call /flightsFuture, the only thing that’s different is which dates return data.
What exactly changed?
The accepted date range. The endpoint previously required a date seven or more days ahead. It now accepts any date from one day ahead onward, up to the existing twelve-month limit.
Is the near-term data from a different source?
The response format is the same and the data is confirmed schedule data, same as the rest of the range. Coverage for very small regional airports can vary slightly in the 1 to 7 day window.
Does this cover the current date?
No. Flights on the current date are served by /flights for live status and /timetable for the scheduled board. /flightsFuture starts at the following day.
This doesn’t change how you query flights. It expands the date range those queries cover.
Aviationstack is one of 25+ APIs on APILayer, all on the same key and the same billing line. Browse the catalog →