Korean Air (Seoul Incheon International Airport, ICN) Flight API

You need to power Korean Air (KE) flight experiences around Seoul Incheon International Airport (ICN)—from accurate schedules to near real-time gate and terminal views—without spending days stitching data together. By the end of this guide, you will query Korean Air schedules, parse the JSON you need (status, times, terminals, gates when combined with live data), and ship resilient polling and caching around FlightLabs’ endpoints.

Who this is for, and what’s unique about KE at ICN

Korean Air (IATA: KE) is South Korea’s flag carrier. Seoul Incheon International Airport (IATA: ICN) is a major global hub for the airline. If you’re building airport displays, travel apps, or logistics dashboards centered on KE movements through ICN, you’ll rely on schedules for planning windows and live tracking for status, delays, and gate changes.

What you can build with KE + ICN data

• Flight status pages for KE departures from ICN that combine published schedules with live status, terminals, and gates.
• Operational delay monitors that alert on late departures or arrivals for KE flights touching ICN, using live status and timestamps.
• Route and schedule explorers to surface when and where KE flies from ICN, useful for planning and customer messaging.

Choosing the right FlightLabs endpoints for KE at ICN

FlightLabs groups aviation data into categories you can combine. For development against Korean Air at Incheon, these are the most relevant:

You will primarily call the schedules endpoint to plan and enumerate KE flights. For live boards and alerts, pair schedules with the real-time category to attach status, terminals, gates, and position when available.

Query KE schedules with ICN context

Use the schedules endpoint to fetch Korean Air operations. The endpoint accepts an IATA code and a type discriminator. Below, iataCode=KE scopes to the airline. The example values are illustrative; times are ISO 8601 and typically expressed in UTC.

curl request (copy-paste ready)

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

Sample JSON response

{
"success": true,
"data": {
"schedules": [
{
"flight_number": "KE907",
"departure": {
"airport": "ICN",
"scheduled": "2024-11-01T09:10:00Z",
"terminal": "2"
},
"arrival": {
"airport": "CDG",
"scheduled": "2024-11-01T17:00:00Z",
"terminal": "2E"
},
"aircraft": {
"type": "Boeing 777-300ER",
"registration": "HLXXXX"
},
"airline": {
"name": "Korean Air",
"iata": "KE"
}
},
{
"flight_number": "KE35",
"departure": {
"airport": "ICN",
"scheduled": "2024-11-01T14:30:00Z",
"terminal": "2"
},
"arrival": {
"airport": "LAX",
"scheduled": "2024-11-01T22:20:00Z",
"terminal": "B"
},
"aircraft": {
"type": "Airbus A380-800",
"registration": "HLYYYY"
},
"airline": {
"name": "Korean Air",
"iata": "KE"
}
}
]
}
}

What matters for KE + ICN builds:

• flight_number: Your stable key for display and linking to live status.
• departure.airport and arrival.airport: IATA codes; use these to filter ICN-centric boards.
• departure.scheduled and arrival.scheduled: ISO 8601 timestamps, typically UTC; convert for Asia/Seoul or destination local time in your UI.
• departure.terminal and arrival.terminal: Useful for ICN terminal 2 displays and wayfinding.
• airline.iata/name and aircraft.type/registration: Display metadata; registration is often static in schedules and can differ in live ops.

JavaScript example: render KE departures from ICN

This snippet fetches Korean Air schedules and filters flights departing ICN. It demonstrates parsing, UTC conversion stubs, and grouping by local hour for boards. Replace YOUR_API_KEY before running.

async function fetchKESchedules() {
const params = new URLSearchParams({
iataCode: "KE",
type: "airline",
access_key: "YOUR_API_KEY"
});
const url = `https://api.goflightlabs.com/flights-schedules?${params.toString()}`;
const res = await fetch(url, { headers: { "Accept": "application/json" } });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const json = await res.json();
if (!json.success) throw new Error("API returned success=false");

const schedules = (json.data && json.data.schedules) || [];
// Focus: KE departures out of ICN
const keFromICN = schedules.filter(s => s.departure && s.departure.airport === "ICN");

// Map for display; convert scheduled UTC to local Asia/Seoul if needed
const displayRows = keFromICN.map(s => {
const depUTC = s.departure.scheduled;
const arrUTC = s.arrival.scheduled;
return {
flight: `KE ${s.flight_number}`,
from: s.departure.airport,
to: s.arrival.airport,
depUTC,
arrUTC,
depTerminal: s.departure.terminal || "",
arrTerminal: s.arrival.terminal || "",
aircraft: (s.aircraft && s.aircraft.type) || ""
};
});

// Example rendering
for (const row of displayRows) {
console.log(`${row.flight} ${row.from} → ${row.to} Dep: ${row.depUTC} (T${row.depTerminal}) Arr: ${row.arrUTC} (T${row.arrTerminal}) ${row.aircraft}`);
}

return displayRows;
}

fetchKESchedules().catch(console.error);

To show live gate or delay status, join a schedule row (by flight number and approximate time window) with live data from the real-time tracking category. Use the live status and the “actual” or “estimated” timestamps to compute delays.

Turn schedules into live KE status at ICN

Schedules give you the baseline. To build a live board:

• Start with the schedule: flight_number, departure.scheduled, terminals.
• Pull real-time flight details to get status (e.g., en-route, landed), departure.actual, arrival.estimated, and any gate fields when present.
• Compute delay = (actual or estimated) − scheduled. Display positive values as minutes late and negative as early.

The real-time JSON structure includes fields like status, departure.actual, arrival.estimated, terminal, gate, and position. Position fields (latitude, longitude, altitude, speed, heading) are helpful for map overlays and ETAs. Use these only when the flight is active; cache gracefully when a given flight isn’t yet emitting live data.

Use cases mapped to fields (KE + ICN)

1) Flight status pages

• Base schedule: departure.scheduled, arrival.scheduled, terminals.
• Live overlay: status, departure.actual, arrival.estimated, terminal/gate changes.
• Display logic: compute delays; switch to gate view for ICN (Terminal 2 for most KE long-haul) when gate is available.

2) Delay monitoring and alerts

• Compare scheduled vs actual/estimated timestamps to derive delay minutes.
• Alert thresholds: e.g., >15-minute departure delay for any KE flight out of ICN.
• Include fallback messaging when live data is temporarily unavailable; continue to show scheduled times from the schedule endpoint.

3) Route and schedule analysis

• Aggregate schedules for KE with departure.airport = ICN to identify destinations and frequency patterns.
• Combine with routes data for broader coverage snapshots.
• Store snapshots daily for historical trend comparisons or seasonal planning views.

Time zones, UTC, and display rules

• Schedules return ISO 8601 timestamps, typically in UTC (Z). Convert to local time zones for customer-facing UIs.
• Asia/Seoul (ICN) does not currently observe daylight saving time, simplifying conversion from UTC. Always confirm locale rules if you display origin and destination times simultaneously.
• When computing delays, do all math in UTC to avoid offset issues, then render in local time.

Polling frequency, caching, and stability

• Schedules: Cache for at least several minutes; refresh on a cadence aligned with your board update interval or user interactions. Schedules don’t change rapidly.
• Live tracking: Poll more frequently only for flights within a certain window (e.g., from T−2h to arrival). Back off to longer intervals outside that window.
• Use ETags or conditional caching if available in your HTTP client, and deduplicate by flight number + date.
• Graceful degradation: If the live call fails or times out, keep the last-known status and fall back to the scheduled times with a “last updated” timestamp.

Handling cancellations, diversions, and codeshares

• Cancellations/diversions: In live data, check status fields. If status indicates cancelled or diverted, suppress gates and show a clear banner.
• Times: For cancelled flights, do not compute delays; instead, display scheduled times with a cancellation badge. For diverted flights, prefer the live arrival fields and clarify the new airport.
• Codeshares: The schedules payload focuses on the marketing flight_number and airline. When combining with live data, normalize by the operating carrier’s flight.iata/icao/number if provided, and map codeshares in your UI to the underlying operation to avoid duplicates.

Pagination, filtering, and windowing strategies

• Schedules often cover many flights. Implement pagination according to the parameters described in the product docs and request smaller time windows when possible.
• Filter server-side where parameters exist (e.g., by airline or airport via iataCode, by type), then filter client-side for specific use cases like “KE departures from ICN this afternoon.”
• Store a compact local index keyed by flight number and scheduled departure date to join schedules to live data quickly without querying both every time.

Development workflow and tools

• API key management: Get your key and rotate it on a regular schedule.
• Test queries in an API console or your terminal first, then move into app code once you’re confident in the filters and fields you need.
• If you need endpoint specifics beyond this article (pagination mechanics, additional filters, or advanced response fields), consult the official docs.

Explore more details and parameters in the Documentation. For testing and orchestration, the MCP can help you organize multiple calls across schedules and live tracking.

Practical comparison: how to combine categories for KE at ICN

• Start with Flight Schedules for breadth: enumerate KE’s daily flights tied to ICN, including terminals.
• Augment with Real-time Tracking for depth: status, gate changes, and current estimates at decision time.
• Add Routes for analytics: baseline route coverage out of ICN to inform planning screens and filters.
• Use Flight History for retrospective analysis: validate operational patterns and improve alert thresholds.

This layered approach keeps your app fast (cache schedules; query live sparingly) while surfacing the critical KE + ICN operational data when users actually need it.

Production notes that save debugging time

• Normalize IATA casing (always uppercase: KE, ICN) to avoid mismatches.
• Deduplicate flights by flight_number + departure.scheduled date; aircraft.registration can vary and should not be used as a unique key.
• Terminal fields may be present on both schedule and live responses; prefer live values when available close to departure/arrival.
• Guard against missing fields: not all schedules include aircraft.registration, and some airports may omit terminal info.
• Log both the raw JSON and your parsed model during integration; many production issues trace back to incorrect nested field handling.

Pricing, access, and next steps

You can start integrating with a short trial (7 days or 50 requests) before choosing a plan. A starter tier is available if you need to move beyond the trial quickly. If you’re building KE + ICN features and need to validate volume and endpoints, sign up and begin with schedules, then layer in live tracking once your UI is wired for status and delay logic.

Get your API key and start testing now: Register

FAQ

• How do I join schedules to live data for KE flights at ICN?

  Use flight_number plus a time window around departure.scheduled to find the corresponding live record. When both marketing and operating numbers exist, normalize on the operating identifier from the live response if provided.

• Are schedule timestamps in local time or UTC?

  They are provided in ISO 8601, typically UTC (ending with Z). Convert to the display locale (e.g., Asia/Seoul for ICN) and perform delay calculations in UTC.

• How often should I poll for live KE flights?

  Poll more aggressively in the T−2h to arrival window (e.g., 30–60 seconds) and back off outside that window. Cache schedules for several minutes or more since they change infrequently.

• How do I handle cancelled or diverted flights?

  Use the live status field. For cancelled, display the schedule with a cancellation badge and stop computing delays. For diverted, indicate the new arrival airport and use live timestamps.

• Can I page through an entire day of KE flights at ICN?

  Yes—use the schedules endpoint with appropriate filters and pagination as documented. Request smaller time windows and iterate, storing results locally to build your daily board.