Korean Air (ICN) Routes API

You need to programmatically list, analyze, and monitor Korean Air (KE) routes—especially to and from Seoul–Incheon (ICN)—without building a data pipeline from scratch. By the end of this guide, you’ll query schedules filtered by airline, interpret the returned fields for routing and status use cases, handle time zones and polling, and structure your caching so ICN-heavy workloads stay fast and cost-effective.

What you’re building with FlightLabs for Korean Air (KE)

Korean Air (IATA: KE) is the flag carrier of South Korea. It operates an extensive international network with a primary hub at Seoul–Incheon International Airport (ICN). In this article, we’ll anchor all examples to KE and ICN, using FlightLabs’ schedules and related endpoints to power routing, status pages, and operational dashboards.

Two quick links while you read: the API home at goflightlabs.com and the self-serve console at MCP.

Choosing the right endpoint for KE routes and ICN operations

There are three categories you’ll likely combine:

• Flight Schedules for KE: filter by IATA to derive routes (origin–destination pairs), plus departure/arrival times, terminals, and gates.
• Real-time Flight Tracking: enrich the same flights with live statuses and positions.
• Routes (reference data): a static or low-frequency layer to map the overall KE network (useful for planning coverage and search indexes).

Query KE schedules from ICN: the quickest “routes” path

While Routes reference data gives you a broad network picture, KE schedules filtered by IATA are ideal for actionable route extraction—day by day, with times and operational details.

curl: list KE schedules by airline IATA

This call requests KE schedules. The type parameter lets you filter by departure or arrival context. In practice, you’ll pair schedules with your own date window logic and cache the results.

curl -G "https://api.goflightlabs.com/flights-schedules" \
--data-urlencode "iataCode=KE" \
--data-urlencode "type=departure" \
--data-urlencode "api_key=YOUR_API_KEY"

Notes:

• iataCode=KE filters to Korean Air.
• type supports values like departure or arrival (use what fits your UI/logic; exact accepted values may vary—confirm in the Documentation).
• Use your own time windowing/pagination strategy when dealing with high-frequency ICN operations.

Python: fetch KE schedules, derive ICN routes, and normalize timestamps

import os
import requests
from datetime import datetime, timezone

API_URL = "https://api.goflightlabs.com/flights-schedules"
API_KEY = os.getenv("FLIGHTLABS_KEY", "YOUR_API_KEY")

def to_utc(dt_str):
# Many FlightLabs times are returned as ISO 8601 in UTC (e.g., 2024-03-20T08:00:00Z).
# Always treat "Z" as UTC and normalize for comparisons.
if not dt_str:
return None
return datetime.fromisoformat(dt_str.replace("Z", "+00:00")).astimezone(timezone.utc)

def fetch_ke_departures():
params = {
"iataCode": "KE",
"type": "departure",
"api_key": API_KEY
}
r = requests.get(API_URL, params=params, timeout=30)
r.raise_for_status()
data = r.json()
return data

def extract_icn_routes(schedule_payload):
routes = set()
schedules = schedule_payload.get("data", {}).get("schedules", [])
for s in schedules:
dep = s.get("departure", {})
arr = s.get("arrival", {})
dep_airport = dep.get("airport")
arr_airport = arr.get("airport")
if dep_airport == "ICN" or arr_airport == "ICN":
if dep_airport and arr_airport:
routes.add((dep_airport, arr_airport))
return sorted(routes)

def list_departure_cards(schedule_payload, limit=10):
schedules = schedule_payload.get("data", {}).get("schedules", [])[:limit]
cards = []
for s in schedules:
fno = s.get("flight_number")
dep = s.get("departure", {})
arr = s.get("arrival", {})
airline = s.get("airline", {})
# Normalize times to UTC for consistent comparisons
dep_sched_utc = to_utc(dep.get("scheduled"))
arr_sched_utc = to_utc(arr.get("scheduled"))
cards.append({
"airline_iata": airline.get("iata"),
"flight_number": fno,
"dep_airport": dep.get("airport"),
"arr_airport": arr.get("airport"),
"dep_scheduled_utc": dep_sched_utc.isoformat() if dep_sched_utc else None,
"arr_scheduled_utc": arr_sched_utc.isoformat() if arr_sched_utc else None,
"dep_terminal": dep.get("terminal"),
"arr_terminal": arr.get("terminal")
})
return cards

if __name__ == "__main__":
payload = fetch_ke_departures()
routes = extract_icn_routes(payload)
print("ICN-involved KE routes (sample):")
for r in routes[:15]:
print(f"{r[0]} -> {r[1]}")

print("\nFirst 10 departure cards for UI:")
for c in list_departure_cards(payload, limit=10):
print(c)

Implementation details:

• Derive KE routes that touch ICN by reading departure.airport and arrival.airport.
• Turn the ISO 8601 times into UTC datetimes immediately. This is critical for delay logic and cross-timezone comparisons.
• Keep arrays small in your UI layer; bulk processing and caching happen server-side.

Field interpretation using official response samples

The exact fields you’ll see for KE schedules and real-time data follow the structure below. The samples are taken from the official examples and illustrate how to interpret the payload for status, terminals, gates, and timestamps.

Real-time flight tracking: status and gates

{
"success": true,
"data": {
"flight": {
"iata": "AA123",
"icao": "AAL123",
"number": "123",
"status": "en-route",
"departure": {
"airport": "JFK",
"scheduled": "2024-03-20T10:00:00Z",
"actual": "2024-03-20T10:05:00Z",
"terminal": "8",
"gate": "B12"
},
"arrival": {
"airport": "LAX",
"scheduled": "2024-03-20T13:15:00Z",
"estimated": "2024-03-20T13:20:00Z",
"terminal": "4",
"gate": "45A"
},
"position": {
"latitude": 39.8729,
"longitude": -98.7372,
"altitude": 35000,
"speed": 495,
"heading": 270
}
}
}
}

How to use these fields for KE/ICN work:

• flight.status: “en-route”, “scheduled”, “landed”, “cancelled”, etc. If you see “cancelled” or “diverted,” branch your UI logic to show advisories and hide countdowns.
• departure/arrival.scheduled, .actual, .estimated: schedule adherence and delay deltas. Compute differences in UTC.
• terminal and gate: drive airport display lines; cache these per flight and update on each poll.
• position.*: optional for KE long-haul route tracking (map overlays and “minutes to go” estimates).

Schedules: planning around terminals and aircraft

{
"success": true,
"data": {
"schedules": [
{
"flight_number": "UA456",
"departure": {
"airport": "SFO",
"scheduled": "2024-03-20T08:00:00Z",
"terminal": "3"
},
"arrival": {
"airport": "ORD",
"scheduled": "2024-03-20T14:15:00Z",
"terminal": "1"
},
"aircraft": {
"type": "Boeing 787-9",
"registration": "N123UA"
},
"airline": {
"name": "United Airlines",
"iata": "UA"
}
}
]
}
}

With KE schedules, you’ll read the same structure:

• flight_number: pair with airline.iata == "KE" to disambiguate codeshares in your UI.
• departure/arrival.airport: route endpoints (e.g., ICN to LAX). This is the most direct route signal.
• departure/arrival.scheduled: plan availability windows, Gantt bars, and ETAs for airport day-of ops.
• terminals: power signage or concierge tools at ICN and destination airports.
• aircraft.*: optional enrichment for customer comms and capacity planning.

Two paths to “KE routes”: schedules vs. routes reference

For developers building KE route maps and ICN-centric UIs, there are two practical strategies. Choose based on your use case and refresh cadence.

Schedules-derived routes (dynamic)

• Method: Call /flights-schedules filtered by iataCode=KE, parse departure.airport and arrival.airport pairs, and aggregate unique O–D pairs over your time window.
• Pros: Time-aligned with actual operations, returns terminals and scheduled times, and easily extended to live updates with real-time status.
• Considerations: Requires pagination/windowing and caching; heavy KE–ICN banks may generate large payloads during peaks.

Routes reference (static/strategic)

• Method: Use the routes reference data described at Routes to compile a KE network baseline.
• Pros: Light-weight and great for search indexes, planning views, or coverage summaries.
• Considerations: For day-of ops or airport board use cases, pair with schedules and real-time tracking for terminals, gates, and delays.

Practical concerns: time zones, polling, caching, and failures

These four issues determine whether your KE/ICN route dashboards are accurate and performant.

Timestamps and time zones

• Use UTC everywhere internally. FlightLabs samples show ISO 8601 with “Z” to denote UTC. Normalize on ingest.
• Display in local time zones at the UI layer (ICN is typically Asia/Seoul). For alerts and SLAs, compute differences in UTC and format locally for users.
• When reconciling schedules with real-time data, prefer actual and estimated over scheduled for customer-facing ETAs.

Polling frequency and live tracking

• Schedules: Cache for minutes to hours depending on the horizon (e.g., next 6–24 hours). Only refresh deltas near departure/arrival windows.
• Real-time status: Poll more frequently close to pushback and arrival; back off in cruise unless your map requires constant updates.
• Position data: If drawing live maps for KE long-hauls, consider a sliding window cache and a “coast” mode that interpolates between updates to reduce requests.

Caching layers for ICN-heavy workloads

• Server cache by (airline IATA, date, type) for schedules. For ICN, split caches by departure vs. arrival to speed common views.
• Invalidate caches on gate/terminal changes or when status transitions (e.g., scheduled → boarding → departed).
• For route pages, precompute unique O–D pairs nightly, but allow ad-hoc “refresh” using near-term schedules to catch seasonal variations.

Handling cancelled, diverted, and irregular ops

• Status field: If a flight is “cancelled,” show the reason UI and suppress countdowns. For “diverted,” add a secondary arrival airport field in your internal model and display an advisory.
• Fallback logic: If real-time data is missing but schedules exist, keep the schedule visible with a “status unavailable” badge.
• Historical lookup: If you reconcile outcomes later, archive actual/estimated times for analytics and customer notifications.

Three KE-focused use cases you can ship fast

1) KE flight status and ICN departure boards

• Primary fields: flight.status, departure/arrival.scheduled, .actual, .estimated, terminal, gate.
• Approach: Preload schedules with iataCode=KE and type=departure; as departure windows approach, overlay real-time status to reflect gate changes or delays.
• ICN nuance: Surface terminal for both departure and arrival; KE operations at ICN often hinge on terminal changes, which affect passenger flows.

2) Delay monitoring and alerting for KE routes

• Primary fields: scheduled vs. actual/estimated times; status transitions.
• Approach: Compute delay deltas in UTC. Alert thresholds can be time-based (e.g., 15+ minutes) or state-based (e.g., “gate change”).
• Storage: Keep a stream of state changes for downstream analytics and post-mortems on ICN banks.

3) Route analysis for KE network planning

• Primary fields: departure.airport and arrival.airport from schedules; optionally merge with routes reference.
• Approach: Derive all unique KE O–D pairs that include ICN for a given season, then compare weekly or monthly. For seasonal changes, combine historical schedules and upcoming future flights for forward-looking coverage.
• UI: Provide filters by origin/destination, plus a heatmap of route counts for KE.

Developer workflow: from sandbox calls to production

• Start in the hosted console: browse responses, test parameters, and inspect payload shape in the MCP.
• Authentication: Use an API key. Keep it in environment variables on servers and CI.
• Pagination: For large schedules, paginate or batch by narrower windows (e.g., per day or per 6-hour block for ICN peaks). If specific pagination parameters are not documented for an endpoint, slice your queries by time and cache results to avoid overfetching.
• Resilience: Implement exponential backoff and circuit breakers. Store the last good response for KE/ICN views so widgets remain functional during transient errors.

A quick, objective comparison of what each data type gives you

End-to-end tips that save you time

• Normalize to UTC immediately and keep formatting local only at render time.
• Derive KE routes from schedules to keep your route list realistic for the period you care about.
• Cache schedules by airline/date/type and only layer in real-time status when a user views a specific flight or when a flight is within a critical window.
• Capture status transitions (“scheduled” → “delayed” → “departed”) for backfill analytics and SLAs.
• For ICN boards, list terminals and gates prominently; ensure deltas or changes are visually emphasized.

Useful links and how to get your key

• Product site: goflightlabs.com
• Read the parameter and schema details: Documentation
• Try calls directly in the console: MCP

FAQ

How do I get a list of all current KE routes involving ICN?
Use /flights-schedules filtered by iataCode=KE and aggregate unique departure.airport → arrival.airport pairs over your date range. Store the set in a cache and refresh on your chosen cadence. For a broader baseline, combine this with the Routes reference data.

What time zone are schedule timestamps in?
The samples show ISO 8601 with Z (UTC). Treat all comparisons (e.g., delays) in UTC. Convert to local time zones (ICN is Asia/Seoul) at the presentation layer.

How often should I poll real-time data for KE long-haul flights?
Increase polling frequency near departure and during approach. For en-route cruise, reduce frequency or interpolate positions to conserve requests while keeping the map smooth.

How do I handle cancelled or diverted KE flights?
Check the status field. If cancelled, show an advisory and stop countdowns. If diverted, display the diversion airport and deprioritize the original arrival terminal/gate in your UI.

Is there a free way to try the API?
Yes. There’s a 7-day or 50 request trial so you can validate your KE/ICN use cases before scaling.

Ready to implement KE route and ICN operations in your product? Get an API key in minutes and start querying schedules and live status: Register. For reference while you build, keep the Documentation open alongside MCP.