Singapore Airlines (HKG) Routes API

You need to list, analyze, and monitor Singapore Airlines (IATA: SQ) routes that touch Hong Kong International Airport (IATA: HKG) and turn that into reliable features like route maps, status pages, and delay alerts. By the end of this walkthrough, you’ll query FlightLabs schedules for SQ, derive route pairs for HKG, and wire up real-time tracking fields for operational monitoring—ready to embed in your app.

Singapore Airlines at a glance

Singapore Airlines (IATA: SQ) is the flag carrier of Singapore. The airline operates globally with a primary hub at Singapore Changi Airport. If your application focuses on SQ flights that depart from or arrive at Hong Kong International Airport (HKG), FlightLabs provides the schedule and live status data you’ll need to build dependable features.

How to surface SQ routes that include HKG

FlightLabs schedules let you derive routes by combining airline and airport filters. Since routes are fundamentally origin–destination pairs, you can pull schedules for Singapore Airlines (SQ) and then filter departures or arrivals that match HKG to enumerate all active (or scheduled) city pairs.

• Use the schedules endpoint to filter by airline IATA code (SQ) and direction type.
• Aggregate by origin/arrival airport codes to enumerate distinct routes that include HKG.
• Optionally, pair schedules with live tracking for status pages and disruption alerts.

Because schedules and real-time status are separate data surfaces, you can combine them at runtime: schedules give you repeatable route structure, while real-time fills in day-of-operational details (status, gates, actual/estimated times).

Which FlightLabs endpoints matter for Singapore Airlines at HKG?

You’ll build on these parts of the platform:

You can explore more details in the Documentation and on the FlightLabs site.

Call the schedules endpoint for SQ (filter by direction, then include HKG)

Below is a simple cURL request to retrieve scheduled flights for Singapore Airlines. You’ll filter to “departure” first; in your code, further reduce the list to those where the origin or destination is HKG depending on your use case.

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

Notes:

• iataCode is the airline code (SQ for Singapore Airlines).
• type can be used to request schedules by direction (e.g., “departure” or “arrival”).
• Attach your API key as a query parameter as shown above.

From the response, you’ll aggregate departure.airport and arrival.airport pairs and then filter those involving HKG to produce the SQ route list to or from Hong Kong.

Understand the schedule shape you’ll receive

This official sample shows the data structure you’ll parse and normalize. Use the airline.iata field to isolate SQ, and filter on departure.airport or arrival.airport equal to HKG depending on your direction.

{
    "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 in your SQ + HKG flow:

• airline.iata: filter to SQ.
• departure.airport and arrival.airport: if either equals HKG, the flight touches Hong Kong.
• departure.scheduled and arrival.scheduled: normalized as UTC timestamps; convert to local time zones for display if needed.
• departure.terminal and arrival.terminal: useful for airport boards and traveler messaging.
• flight_number and aircraft: presentational context for app UX and analytics.

JavaScript example: build a Singapore Airlines HKG route map

This Node.js sample calls schedules for SQ, converts schedule pairs to distinct routes that include HKG, and groups by direction for UI display. Replace YOUR_API_KEY with your key.

import fetch from "node-fetch";

const API = "https://api.goflightlabs.com/flights-schedules";
const API_KEY = "YOUR_API_KEY";
const AIRLINE_IATA = "SQ";
const HKG = "HKG";

async function fetchSchedules({ iataCode, type }) {
  const url = new URL(API);
  url.searchParams.set("iataCode", iataCode);
  url.searchParams.set("type", type);
  url.searchParams.set("access_key", API_KEY);
  const res = await fetch(url.toString());
  if (!res.ok) throw new Error("FlightLabs request failed: " + res.status);
  const body = await res.json();
  return body?.data?.schedules || [];
}

function toRouteKey(origin, dest) {
  return origin + "-" + dest;
}

async function main() {
  // Pull both departures and arrivals for SQ, then isolate flights that touch HKG
  const [dep, arr] = await Promise.all([
    fetchSchedules({ iataCode: AIRLINE_IATA, type: "departure" }),
    fetchSchedules({ iataCode: AIRLINE_IATA, type: "arrival" })
  ]);

  const touchingHKG = [...dep, ...arr].filter(s => {
    const origin = s?.departure?.airport;
    const dest = s?.arrival?.airport;
    return origin === HKG || dest === HKG;
  });

  // Derive distinct routes and label direction relative to HKG
  const routes = new Map();
  for (const s of touchingHKG) {
    const origin = s?.departure?.airport;
    const dest = s?.arrival?.airport;
    const airline = s?.airline?.iata;
    if (airline !== AIRLINE_IATA || !origin || !dest) continue;

    const key = toRouteKey(origin, dest);
    if (!routes.has(key)) {
      routes.set(key, {
        origin,
        dest,
        flights: []
      });
    }
    routes.get(key).flights.push({
      flight_number: s?.flight_number,
      dep_scheduled_utc: s?.departure?.scheduled,
      arr_scheduled_utc: s?.arrival?.scheduled,
      dep_terminal: s?.departure?.terminal,
      arr_terminal: s?.arrival?.terminal,
      aircraft_type: s?.aircraft?.type
    });
  }

  // Present routes, grouped by whether they depart from or arrive at HKG
  const departuresFromHKG = [];
  const arrivalsToHKG = [];
  for (const r of routes.values()) {
    if (r.origin === HKG) departuresFromHKG.push(r);
    if (r.dest === HKG) arrivalsToHKG.push(r);
  }

  console.log("SQ routes departing HKG:");
  for (const r of departuresFromHKG) {
    console.log(`  ${r.origin} -> ${r.dest} (${r.flights.length} scheduled entries)`);
  }
  console.log("SQ routes arriving HKG:");
  for (const r of arrivalsToHKG) {
    console.log(`  ${r.origin} -> ${r.dest} (${r.flights.length} scheduled entries)`);
  }
}

main().catch(err => {
  console.error(err);
  process.exit(1);
});

Production tips:

• UTC handling: departure.scheduled and arrival.scheduled are UTC ISO timestamps. Convert to local time zones only when rendering; keep UTC internally for comparisons and analytics.
• Stability: cache schedules aggressively (e.g., hourly or daily refresh) and separately poll live status for operational updates.
• Pagination: if schedules span many flights for SQ, handle pagination as documented. If response paging fields are present in your plan, loop until all pages are collected.

Add live status for SQ flights touching HKG

Once you’ve derived routes, wire in real-time status to keep your boards and alerts fresh. The following official sample shows the shape of live tracking data returned by FlightLabs. The fields “status,” “scheduled/actual/estimated” times, “terminal,” “gate,” and “position” are central to status pages, delay detection, and client notifications.

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

Field behaviors you’ll likely code against for SQ + HKG:

• status: values like “scheduled,” “active,” “en-route,” “landed,” “cancelled,” or “diverted” (exact value lists may vary by data source; handle them defensively).
• departure.scheduled vs departure.actual: compute off-block or pushback delays.
• arrival.scheduled vs arrival.estimated: power ETA countdowns and connect-time logic.
• terminal and gate: display prominently on your HKG boards and traveler notifications.
• position: use for maps and arrival-range estimates when status is “en-route.”

You can access tooling and testing via MCP and the main site at goflightlabs.com.

Practical implementation details for HKG-focused apps

Time zones and UTC

Keep all computations in UTC as provided by the API (e.g., departure.scheduled, arrival.estimated). Convert to Asia/Hong_Kong or origin/destination local times only in views. If you log or alert, include both UTC and local to simplify debugging.

Polling frequency and caching

• Schedules: cache for longer periods (e.g., hours to a day) and refresh off-peak. Schedules don’t change frequently, and you only need them to derive route maps and planned times.
• Real-time status: poll more frequently during the operational window of SQ flights touching HKG. A cadence of a few minutes is typical; tune based on your plan’s quotas and the UX you need.
• Client caching: use ETag/If-Modified-Since or your own hash of the JSON to avoid processing identical payloads.

Handling cancelled, delayed, or diverted flights

• Cancelled: if status indicates a cancellation, mark the flight clearly; keep the schedule row but block seat map or gate info.
• Delayed: compute delays with actual vs scheduled for departures and estimated vs scheduled for arrivals; color code in the UI and surface reasons if you collect them separately.
• Diverted: a diverted status should suppress arrival gate at HKG and annotate the diverted airport if you track it from other reference data.

Pagination and large result sets

If your SQ + HKG schedules pull spans a large dataset, implement pagination as described in the API docs. Loop through pages and aggregate results before computing distinct routes. Store route keys (e.g., origin-destination pairs) in a set to avoid duplicates.

Codeshares and branding

When building SQ-focused views, filter primarily by airline.iata = "SQ". If you surface codeshares, label both operating and marketing carriers where available in your app’s data model. If you only need SQ-operated flights, filter out entries where the operating airline is not SQ.

Terminals and gates at HKG

Terminals and gates appear within the schedule and live responses when available (e.g., departure.terminal, arrival.gate). For a better passenger experience, render gates only when you have a non-empty value; otherwise, show “TBD” and refresh live status more frequently near scheduled times.

Use cases centered on SQ routes that include HKG

1) Airline-specific HKG departures board

Filter schedules with airline.iata = SQ and departure.airport = HKG. Render flight_number, destination (arrival.airport), departure.scheduled (local time), and departure.terminal/gate. Augment each row with live status fields—status, departure.actual—during the departure window for accuracy.

2) Delay monitoring for SQ at HKG

Maintain a watch list of SQ flights to/from HKG based on your route set. Poll live status to compare scheduled vs actual/estimated. Trigger alerts when difference thresholds are exceeded. Use terminal/gate to route ground-team notifications.

3) Route analysis for SQ network design

Aggregate distinct origin–destination pairs that touch HKG from the schedules feed. Count schedules per route and correlate with your internal metrics. Because times are in UTC, you can compare cross-region services without time-zone skew.

Objective, developer-focused comparison: schedules vs live tracking vs routes reference

Combining these gives you the best of both worlds: schedules to define SQ routes that include HKG, and live data to keep each service accurate in your app.

Security, pricing, and getting started

• Authentication: calls are authenticated with an API key. Keep it server-side where possible.
• Starter: $24.99/mo.
• Trial: 7 days or 50 requests (whichever is reached first).

Set up your environment, generate a key, and run a few requests in minutes. Visit goflightlabs.com to learn more or jump into the Register flow to obtain your API key.

FAQ

How do I filter specifically for Singapore Airlines and HKG?
Use iataCode=SQ on schedules, then filter results in your code where departure.airport === "HKG" (for departures) or arrival.airport === "HKG" (for arrivals). Keep both for a complete HKG route map.

How should I handle time zones?
All timestamps in examples are UTC ISO strings. Keep your internal logic in UTC. Convert to local time zones at render time, e.g., Asia/Hong_Kong for HKG displays.

What about large schedule responses and pagination?
Implement pagination as documented for your plan level. Iterate through pages to collect all schedules before deduplicating routes by origin/destination.

How often should I poll for live status?
Cache schedules for hours or longer. For live status, poll more frequently (e.g., every few minutes) during pre-departure and approach windows, then slow down outside operational periods.

Can I detect cancellations or diversions?
Yes. Inspect the status field in the live response. Treat “cancelled” and “diverted” as special cases in your UI and downstream logic, and suppress inconsistent gate/terminal displays when a diversion occurs.

Ready to build SQ + HKG route features that ship? Start with the schedules and real-time endpoints in the Documentation, then get your key via Register and test live calls in MCP.