Kansas City Charles B. Wheeler Downtown Airport Real-Time Flight Status API

You need to monitor live movements into and out of a specific airfield, plug that data into boards and alerts, and keep it reliable without over-polling. By the end of this guide, you’ll be able to use the FlightLabs Real-Time Flight Status endpoint to track flights for Kansas City Charles B. Wheeler Downtown Airport (IATA: MKC, ICAO: KMKC), parse the results you care about (status, times, terminals/gates, position), and wire them into your apps.

Why MKC matters for developers

Kansas City Charles B. Wheeler Downtown Airport sits just north of downtown Kansas City, Missouri. It uses IATA code MKC and ICAO code KMKC. Developers track MKC to power FBO and GA operations dashboards, downtown event logistics, and to sync schedules and alerts for corporate shuttles and charters that frequently use this city-center airport.

What the Real-Time Flight Status endpoint returns (and how to use it for MKC)

The Real-Time Flight Tracking endpoint returns current flight records with status, schedule and operational fields, plus an optional live position. You can filter results to the flights you need—by airline, flight, or airport—then use a small set of fields to drive most use cases:

• flight.status: life-cycle state (scheduled, en-route, landed, cancelled, diverted).
• departure.scheduled/actual and arrival.scheduled/estimated: UTC timestamps you can convert to the local time zone for display.
• departure.terminal/gate and arrival.terminal/gate: where published.
• position: live lat/lon, altitude, speed, heading for tracking views.

Below is a curl request to the real-time endpoint. Filtering parameters vary by integration needs; consult the documentation for available filters. The example response illustrates flights where MKC appears as either departure or arrival.

Real-time: curl request

curl -s "https://www.goflightlabs.com/real-time?api_key=YOUR_API_KEY"

Example JSON (values are illustrative)

{
  "success": true,
  "data": {
    "flight": {
      "iata": "XY201",
      "icao": "XYZ201",
      "number": "201",
      "status": "en-route",
      "departure": {
        "airport": "MKC",
        "scheduled": "2024-03-20T11:30:00Z",
        "actual": "2024-03-20T11:38:00Z",
        "terminal": "A",
        "gate": "3"
      },
      "arrival": {
        "airport": "DEN",
        "scheduled": "2024-03-20T13:10:00Z",
        "estimated": "2024-03-20T13:05:00Z",
        "terminal": "1",
        "gate": "B22"
      },
      "position": {
        "latitude": 39.55,
        "longitude": -101.20,
        "altitude": 32000,
        "speed": 470,
        "heading": 265
      }
    }
  }
}

Field highlights you’ll actually use:

• status indicates live state and exceptional cases (e.g., cancelled, diverted).
• departure.scheduled vs departure.actual lets you compute pushback delays for reporting.
• arrival.scheduled vs arrival.estimated drives ETA boards and alerts.
• terminal/gate is display-ready when provided.
• position fields feed maps and telemetry overlays; units are degrees (lat/lon), feet (altitude), knots or mph for speed depending on integration—treat as numeric and display with unit labels your UI expects.

JavaScript integration example: filter MKC flights and normalize times

The snippet below fetches real-time data, filters for MKC as arrival or departure airport, and normalizes timestamps (they arrive in UTC). You can display them in America/Chicago for MKC users, or keep everything in UTC for backend logic.

async function fetchMkcRealTime() {
  const url = "https://www.goflightlabs.com/real-time?api_key=YOUR_API_KEY";
  const res = await fetch(url);
  if (!res.ok) throw new Error("Network error: " + res.status);
  const payload = await res.json();
  if (!payload.success) throw new Error("API error");

  // Normalize to array if API returns a single object in data.flight
  const flights = Array.isArray(payload.data.flight) ? payload.data.flight : [payload.data.flight];

  // Filter: MKC as either departure or arrival airport code
  const mkcFlights = flights.filter(f =>
    f && f.departure && f.arrival && (f.departure.airport === "MKC" || f.arrival.airport === "MKC")
  );

  // Map to UI-ready objects
  return mkcFlights.map(f => {
    const status = f.status;
    const dep = f.departure || {};
    const arr = f.arrival || {};
    const pos = f.position || {};

    // Timestamps are UTC in ISO 8601; parse as-needed
    const depSchedUtc = dep.scheduled ? new Date(dep.scheduled) : null;
    const depActualUtc = dep.actual ? new Date(dep.actual) : null;
    const arrSchedUtc = arr.scheduled ? new Date(arr.scheduled) : null;
    const arrEstUtc = arr.estimated ? new Date(arr.estimated) : null;

    return {
      flightIata: f.iata,
      flightIcao: f.icao,
      number: f.number,
      status,
      depAirport: dep.airport,
      depScheduledUtc: depSchedUtc,
      depActualUtc: depActualUtc,
      depTerminal: dep.terminal || null,
      depGate: dep.gate || null,
      arrAirport: arr.airport,
      arrScheduledUtc: arrSchedUtc,
      arrEstimatedUtc: arrEstUtc,
      arrTerminal: arr.terminal || null,
      arrGate: arr.gate || null,
      position: pos.latitude ? {
        lat: pos.latitude,
        lon: pos.longitude,
        altitude: pos.altitude,
        speed: pos.speed,
        heading: pos.heading
      } : null
    };
  });
}

// Example usage
fetchMkcRealTime()
  .then(list => {
    // Cache these results for 15–30 seconds for dashboards
    console.log("MKC flights:", list);
  })
  .catch(err => console.error(err));

Notes:

• All timestamps in the example payload are UTC. Convert to the user’s time zone for UI, but keep UTC internally for consistency across airports.
• Not every flight includes gate/terminal or live position. Code defensively for missing fields.
• If the endpoint returns a single flight object rather than a list, normalize it to an array as shown.

Use cases at MKC: from arrival boards to delay alerts

1) Arrival and departure boards for MKC

Drive a clean board by reading:

• flight.iata and flight.number for labeling.
• status to group by “Scheduled,” “En Route,” “Landed,” “Cancelled.”
• arrival.estimated and departure.actual to surface current ETAs and delays.
• arrival.terminal/gate and departure.terminal/gate when present.

Polling: 10–15 seconds for lobby displays with real-time positions; 30–60 seconds if you do not show a moving map. Apply a small debounce and cache layer to avoid jitter.

2) Delay and disruption alerts for MKC-bound flights

Trigger notifications when:

• status changes to cancelled or diverted.
• difference between arrival.estimated and arrival.scheduled exceeds a threshold (e.g., 20 minutes).
• departure.actual deviates significantly from departure.scheduled for outbound flights.

Ensure idempotency by logging last-seen status/timestamps per flight so repeated polls do not generate duplicate alerts.

3) Schedule sync for MKC operations

Use Flight Schedules to pre-populate expected movements, then overlay Real-Time to reconcile on-the-day changes:

• Pre-load with schedules.schedules[].departure/arrival.scheduled fields for planning.
• On day-of, reconcile with real-time departure.actual/arrival.estimated and status.
• Archive final performance (actual vs scheduled) with Flight History for analytics.

Comparing FlightLabs endpoints for MKC workflows

Different workflows at MKC benefit from different endpoints. Here is a technical comparison focused on purpose and fields you’ll likely use. Use this to decide which to call, when, and how to cache.

Implementation notes:

• Start with Schedules to establish a baseline list for MKC, then enrich with Real-Time and optionally Delay Predictions for alerts.
• For historical KPI reporting, call Flight History to record final outcomes instead of inferring from the last real-time poll.
• If you need to query by MKC in any endpoint, consult the FlightLabs documentation for supported filters and pagination details.

Handling time zones, polling, caching and edge cases at MKC

Time zones:

• All sample timestamps are ISO 8601 in UTC (e.g., 2024-03-20T11:30:00Z). Store as UTC and convert on read for UI in America/Chicago (MKC’s local time) or the user’s preference.
• When comparing scheduled vs actual/estimated, keep both in UTC to avoid DST edge cases.

Polling and caching:

• Live boards with positions: poll every 10–15 seconds and cache short (e.g., 10–30 seconds) to smooth updates.
• Operational dashboards without maps: 30–60 seconds is typically sufficient.
• Schedules: cache for hours or until the next known update window.

Cancelled, diverted, and irregular operations:

• status may report cancelled or diverted. Handle these explicitly in your UI and alerts.
• If a flight is diverted, arrival.airport will reflect the new destination when available; do not assume MKC remains the arrival airport once diverted.
• Not all cancelled flights include gate/terminal data; guard against null fields.

Pagination and result sizes:

• Schedules and historical queries can return many records. Use pagination as documented and stream or batch ingest them for MKC.
• For real-time, keep responses small by filtering to MKC or a subset of airlines/flight numbers when possible (see documentation for filter options).

Building an MKC arrival board step by step

1) Seed with scheduled arrivals

Use Flight Schedules to get a list of expected inbound flights to MKC for your time window. Store flight_number, arrival.scheduled (UTC), and airline info to label the board.

2) Overlay live status

Call the Real-Time endpoint on a short interval. Join by flight.iata or flight.icao (and time proximity) to locate the live record for each scheduled arrival. Replace scheduled times with arrival.estimated and show status. If departure.actual exists and the flight is en-route, compute a live delay metric as (arrival.estimated - arrival.scheduled).

3) Fallbacks and gaps

When terminal/gate is missing, display “TBD” and avoid placeholders that imply certainty. If the position block is absent, skip the moving map and keep textual status updates only.

Example: combining scheduled and live MKC data

This sketch shows how you might merge Schedules and Real-Time records for MKC arrivals. Adjust to your datastore and paging strategy.

async function mergeMkcArrivals() {
  // Fetch planned schedules (consult docs for filtering/pagination)
  const schedulesRes = await fetch("https://www.goflightlabs.com/flights-schedules?api_key=YOUR_API_KEY");
  const schedulesJson = await schedulesRes.json();
  const schedules = (schedulesJson.data && schedulesJson.data.schedules) || [];

  // Fetch live flights
  const liveRes = await fetch("https://www.goflightlabs.com/real-time?api_key=YOUR_API_KEY");
  const liveJson = await liveRes.json();
  const liveFlights = Array.isArray(liveJson.data.flight) ? liveJson.data.flight : [liveJson.data.flight];

  // Index live flights by IATA code (fallback to ICAO/number as needed)
  const liveByIata = new Map();
  for (const f of liveFlights) {
    if (f && f.iata) liveByIata.set(f.iata, f);
  }

  // Merge by arrival airport MKC and matching flight code
  const mkcArrivals = [];
  for (const s of schedules) {
    const sArr = s.arrival || {};
    if (sArr.airport !== "MKC") continue;

    const code = s.flight_number ? s.flight_number : undefined; // high-level placeholder
    const live = code && liveByIata.has(code) ? liveByIata.get(code) : null;

    mkcArrivals.push({
      airline: s.airline,
      scheduledArrivalUtc: sArr.scheduled ? new Date(sArr.scheduled) : null,
      liveStatus: live ? live.status : "scheduled",
      liveEtaUtc: live && live.arrival ? new Date(live.arrival.estimated) : null,
      gate: (live && live.arrival && live.arrival.gate) || null,
      terminal: (live && live.arrival && live.arrival.terminal) || null
    });
  }

  return mkcArrivals;
}

Because identifiers and filters vary by integration, verify your join keys and sorting rules against your data sample, and prefer UTC-based time proximity to disambiguate same-number flights.

Operational tips specific to MKC

• General aviation and charter: Expect variability in gate/terminal fields. Present flexible layouts that can hide these fields when not available.
• Position-based ETAs: Some MKC traffic may not provide frequent position updates. Fall back to schedule-derived ETAs and update when estimates appear.
• Event-driven spikes: During downtown events, cache and rate-limit smartly. Consider staggering polls across endpoints to avoid thundering herds.

Testing and monitoring

• Use a known time window with higher MKC activity to validate your filters and UI states (scheduled, en-route, landed, cancelled, diverted).
• Log raw payloads for a small rolling window to debug field-level changes and occasional nulls.
• Treat status transitions as a state machine: scheduled → en-route → landed or cancelled/diverted. This prevents regressions in UI when intermittent data arrives.

Security and deployment checklist

• Keep your API key server-side. If you must call from the browser, proxy through your backend.
• Implement retry with backoff on transient network errors. Avoid infinite loops; cap retries.
• Instrument latency and error rates per endpoint. Alert when upstream failures exceed a threshold.
• Version your integration so schema or filter changes can be rolled out safely.

FAQ

How do I filter real-time flights specifically for MKC?
Filtering options are available; consult the documentation for the exact query parameters to restrict results to MKC as departure or arrival. If you cannot filter upstream, fetch and filter client-side by departure.airport or arrival.airport equal to "MKC".

What time zone should I use for timestamps?
Timestamps are provided in UTC. Store and compare in UTC, then convert to America/Chicago for MKC user interfaces or to the viewer’s local time zone for client apps.

How often should I poll the Real-Time endpoint?
For moving maps or tight ETAs, 10–15 seconds is common. For boards without maps, 30–60 seconds reduces noise and cost. Always cache results briefly to avoid jitter and duplicate alerts.

How do I handle cancelled or diverted flights?
Watch the flight.status field. If cancelled, stop ETA updates and annotate the board. If diverted, expect arrival.airport to reflect the new destination when available; remove it from MKC arrivals and, if needed, surface a diversion notice.

Is pagination required for schedules?
Schedules queries can return many records. Use pagination as documented and process in batches. Cache results and refresh incrementally rather than re-pulling entire periods.

Ready to integrate MKC into your app with live status and schedules? Start with the documentation and request access: FlightLabs documentation and Get your FlightLabs API key.