API to Get Cathay Pacific (CX) Flights

You need to programmatically fetch Cathay Pacific (IATA: CX) flights to power status pages, airport displays, or analytics. By the end of this guide, you’ll query Cathay Pacific schedules, pair them with live status, and design polling and caching so your app stays fast and accurate.

What you’ll build with Cathay Pacific (CX) data

Cathay Pacific (CX) is a Hong Kong-based carrier, and many of its long-haul and regional routes pass through Hong Kong International Airport. Using the FlightLabs API, you can fetch:

• Published CX schedules to plan displays and ETAs.
• Live CX flight status and positions to surface delays, gates, and diversions.
• CX routes and future flights for planning and analytics.

All data is served as JSON over a REST API and authenticated with an API key. Explore the platform on goflightlabs.com and use the unified console at MCP once you have credentials.

Core endpoints you’ll use for Cathay Pacific

Here are the FlightLabs endpoints most relevant to CX. Each returns structured JSON you can directly consume.

How to fetch Cathay Pacific schedules

Schedules are the planning backbone for airport displays and logistics. Filter by the airline IATA code CX and specify schedule type (departure or arrival). The base API host is https://api.goflightlabs.com/.

cURL request: CX departures schedule

Use your API key to authenticate. The example below requests published departures for CX and limits the response size for pagination control.

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

Notes:

• iataCode=CX restricts results to Cathay Pacific only.
• type=departure vs type=arrival controls direction.
• limit is shown as an example of pagination. If you expect high volume, use a limit and a continuation mechanism such as an offset or cursor if supported; if not specified in your plan, paginate by time ranges (e.g., hour blocks) to bound result sets.

JavaScript example: render a CX schedule board

async function fetchCathayDepartures() {
  const params = new URLSearchParams({
    iataCode: 'CX',
    type: 'departure',
    limit: '50',
    api_key: 'YOUR_API_KEY'
  });
  const url = `https://api.goflightlabs.com/flights-schedules?${params.toString()}`;

  const res = await fetch(url, { method: 'GET' });
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  const json = await res.json();

  // Expect a structure similar to the official schedule sample:
  // data.schedules[] with flight_number, departure, arrival, aircraft, airline
  const rows = (json.data && json.data.schedules) ? json.data.schedules : [];

  // Map into a minimal board model
  return rows.map(s => ({
    flight: `${s.airline?.iata || 'CX'} ${s.flight_number || ''}`.trim(),
    dep_airport: s.departure?.airport,
    dep_scheduled_utc: s.departure?.scheduled,   // ISO UTC
    dep_terminal: s.departure?.terminal,
    arr_airport: s.arrival?.airport,
    arr_scheduled_utc: s.arrival?.scheduled,     // ISO UTC
    arr_terminal: s.arrival?.terminal,
    aircraft_type: s.aircraft?.type
  }));
}

// Example usage
fetchCathayDepartures()
  .then(board => {
    // Render your rows; convert UTC timestamps to local time zones for the UI
    console.log(board.slice(0, 5));
  })
  .catch(err => console.error(err));

Display times in local time zones for users but keep UTC in storage and logging. Schedules provide planned times; to show real-time gates and status, pair each result with a lookup to the Real-time endpoint using flight identifiers (e.g., IATA code and number).

Field-by-field: what you’ll read from responses

Below are official sample payloads to illustrate structure and the fields that matter for status pages, alerts, and maps. Use these as a schema reference while testing against CX.

Official sample: Real-time Flight Tracking

{
    "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
            }
        }
    }
}

What to use:

• flight.status: e.g., scheduled, en-route, landed, cancelled, diverted.
• departure.scheduled vs departure.actual: delay calculation and ETD display.
• arrival.scheduled vs arrival.estimated: ETA and connection risk.
• departure.terminal/gate and arrival.terminal/gate: signage and wayfinding.
• position.latitude/longitude/altitude/speed/heading: progress map and telemetry.

Official sample: Flight Schedule

{
    "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"
                }
            }
        ]
    }
}

What to use:

• flight_number and airline.iata: compose the IATA flight code (e.g., CX 255).
• departure/arrival.airport: show IATA airport codes for origin/destination.
• departure/arrival.scheduled: use these UTC timestamps for planning.
• departure/arrival.terminal: display terminal info where provided.
• aircraft.type and aircraft.registration: aircraft context for enthusiasts or operational tooling.

How to join schedules with live status for CX

Building a complete CX board typically means:

1. Query schedules for CX by direction (departure or arrival) and time window.
2. For each listed flight, resolve live status and gate information via the Real-time endpoint using the flight’s IATA code and number.
3. Cache schedule rows for 30–60 minutes and refresh live status every 15–60 seconds for en-route flights, 2–5 minutes for scheduled flights not yet boarded, and 60–120 seconds for completed flights. Adjust polling intervals downward during peak traffic to control costs and upward for calmer periods.

Keep everything in UTC for storage and internal joins. Convert to local time zones (e.g., Hong Kong Time for HKG) only at the presentation layer. This avoids DST edge cases and simplifies cross-timezone boards for CX’s global network.

Handling edge cases for Cathay Pacific operations

• Cancelled flights: When flight.status is cancelled, hide gates, show the cancellation prominently, and stop frequent polling for that flight (e.g., back off to 10–15 minute checks).
• Diverted flights: If status indicates diverted, display the diversion airport and suppress the original arrival gate. Continue polling to capture subsequent repositioning.
• Delayed departures: Compute delays from departure.actual - departure.scheduled. For arrivals, use arrival.estimated - arrival.scheduled. Store both differences in minutes for alerting logic.
• Codeshares: If your response includes airline.iata and a codeshare partner in another field, prefer the “operating carrier” for the aircraft and status, but show the CX marketed code on CX-branded surfaces. If codeshares are not present in your plan, treat the schedule row as the operating carrier entry.

Comparison: Which FlightLabs endpoint fits your CX use case?

This is a technical comparison of the endpoints you might combine for Cathay Pacific data. Choose based on the fields you need and your update cadence.

Three practical CX implementations

1) CX flight status pages for web and mobile

• Fetch CX schedules for the flight search date to help users find the correct flight number.
• Pull live data: read flight.status, departure.actual/gate/terminal, and arrival.estimated/gate/terminal for the specific CX flight.
• Highlight delay: departure.actual - departure.scheduled and arrival.estimated - arrival.scheduled. If cancelled, show status and remove gates.

2) Delay monitoring and alerts for corporate travel

• Track a watchlist of CX flights. Poll the Real-time endpoint at a moderate interval (e.g., 60 seconds) from scheduled -90 minutes to arrival +30 minutes.
• Trigger alerts on status changes (scheduled → active, en-route → landed, any → cancelled) and when absolute delay exceeds your threshold.
• Throttle and dedupe notifications so travelers get one clean message per inflection point.

3) Route analysis and connectivity for CX network planning tools

• Combine Routes to enumerate CX city pairs with Schedules to see planned frequencies over your time span.
• Overlay Flight History to compute distributions of departure and arrival deltas for each route.
• Cache results and recompute weekly to keep dashboards responsive.

Working with time zones, polling, and caching

• Time zones: All examples show ISO timestamps with Z (UTC). Store and compare in UTC. Convert to local time zones only when rendering (e.g., Asia/Hong_Kong for HKG).
• Polling: For CX flights in-air, 15–60 second polling gives a live map without overloading your quota. For pre-departure or post-arrival windows, 2–5 minute polling is usually enough.
• Caching: Cache Schedules for at least 30 minutes; gate and status fields should bypass cache or have very short TTLs.
• Pagination: Use limit when available. If offset or cursors aren’t documented for your plan, partition queries by narrow time ranges per request to prevent oversized payloads.

Airport context for display integration

When building a CX board for an airport, you may also need airport metadata like time zone or terminals. Here’s the official airport information sample for structure reference.

{
    "success": true,
    "data": {
        "airport": {
            "iata": "JFK",
            "icao": "KJFK",
            "name": "John F. Kennedy International Airport",
            "location": {
                "lat": 40.6413,
                "lon": -73.7781,
                "city": "New York",
                "country": "United States"
            },
            "timezone": "America\/New_York",
            "terminals": [
                "1",
                "2",
                "4",
                "5",
                "7",
                "8"
            ],
            "runways": [
                {
                    "length_ft": 14511,
                    "width_ft": 150,
                    "surface": "concrete",
                    "designator": "13L\/31R"
                }
            ],
            "weather": {
                "temp_c": 22,
                "visibility_km": 10,
                "wind": {
                    "speed_kts": 8,
                    "direction_deg": 180
                }
            }
        }
    }
}

Use airport.timezone to correctly convert UTC timestamps for passenger-facing boards. Terminal lists can help validate whether terminal values in schedules or live data are expected for that station.

Authentication, pricing, and getting started

• Authentication: Requests are authenticated with an API key. Store it securely server-side and never embed in public client apps without a proxy.
• Pricing: Starter is $24.99/month. A trial is available (7 days or 50 requests) to validate your CX integration.
• Register: Create an account and get your key via Register.
• Docs: Review endpoint details, fields, and examples in the Documentation.

Explore more on the homepage: goflightlabs.com. For account and usage management, use MCP. You can also discover platform updates on the main site.

Putting it together: a CX-focused workflow

1. Schedules pull (CX, departure or arrival, by hour window). Store results with a 30–60 minute TTL.
2. For flights starting within the next 180 minutes or currently en-route, poll Real-time to attach status, gate, and ETA/ETD. Store live overlays with short TTLs (15–60 seconds for in-air flights).
3. If a flight turns cancelled or diverted, adjust UI immediately and reduce or stop frequent polling for that flight to control costs.
4. Aggregate historical results nightly for analytics if you need operational insights by CX route.

FAQ

• How do I filter specifically for Cathay Pacific flights? Use the airline IATA code CX in queries where supported (e.g., iataCode=CX on schedules). For live lookups, use the CX IATA flight code (e.g., CX 255) when calling the Real-time endpoint.
• Which timestamps are UTC vs. local? The samples show ISO 8601 UTC (with Z). Store and compare in UTC. Convert to the local airport time zone for display using the airport.timezone reference if needed.
• How should I handle cancelled or diverted CX flights? Watch flight.status from the Real-time endpoint. If cancelled, suppress gates and stop frequent polling. If diverted, show the diversion airport and continue light polling for updates.
• What’s a good polling frequency for live CX tracking? For in-air flights, 15–60 seconds keeps maps smooth. For pre-departure or post-arrival states, 2–5 minutes is usually sufficient. Always cache schedule data with a longer TTL.
• How do I manage pagination for large CX schedules? Use a limit parameter if available and paginate by time slices (e.g., per-hour windows). If offsets or cursors aren’t documented for your plan, splitting by time windows prevents oversized responses.

Ready to build with Cathay Pacific flight data? Get your API key via Register, explore the Documentation, and start prototyping against goflightlabs.com today.