Air New Zealand (SIN) Airports API

You need to power an Air New Zealand (IATA: NZ) integration centered on Singapore Changi Airport (IATA: SIN): fetch upcoming schedules, track live status and gates, and surface delays reliably. By the end of this guide you will be able to call FlightLabs endpoints to retrieve Air New Zealand schedules, read live status fields you’ll actually use (status, terminals, gates, times), and implement polling, caching, and fallback logic suitable for production.

Air New Zealand context for this build

Air New Zealand (IATA: NZ) is the flag carrier of New Zealand. Its primary hub is Auckland (AKL). In this guide, we focus on building around Air New Zealand flights that arrive to or depart from Singapore Changi (SIN), using FlightLabs scheduling and tracking data.

Which FlightLabs endpoints to use for NZ at SIN

To plan, display, and monitor Air New Zealand flights related to SIN, you’ll typically combine scheduling with live status and route context. The categories below map to the endpoints documented by FlightLabs and how they apply to NZ-SIN use cases.

Requesting Air New Zealand schedules (focused on NZ + SIN)

Use the schedules endpoint to collect planned flights by airline. Then filter client-side to SIN for your display or workflow. The documented pattern is to supply an airline IATA code and a type selector.

curl -s "https://api.goflightlabs.com/flights-schedules?iataCode=NZ&type=airline" \
-H "apikey: YOUR_API_KEY"

Notes:

• iataCode=NZ targets Air New Zealand by airline code.
• type=airline tells the endpoint you’re querying by airline rather than, for example, by airport.
• Filter to SIN on the client by checking departure.airport == "SIN" or arrival.airport == "SIN" in each schedule record, depending on your use case.
• Schedules are typically in UTC timestamps (e.g., 2024-03-20T08:00:00Z). Convert to local time for user display and retain UTC internally for comparisons.

Official Flight Schedule JSON you’ll parse

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

How this maps to your NZ + SIN implementation:

• data.schedules[] is the array you iterate through.
• airline.iata should equal "NZ" for Air New Zealand results. In your code, ignore any records not matching NZ when querying broader datasets.
• departure.airport and arrival.airport are IATA codes (e.g., "SIN"). Use these to select only flights that depart from or arrive at SIN.
• departure.scheduled and arrival.scheduled are UTC ISO-8601 times; convert to user-preferred time zones for display. Keep UTC for logics like sorting and SLA checks.
• terminal fields are useful for airport boards and gate proximity features; gates may be present in other endpoints (e.g., real-time status) and should override schedules when available.

Live status for Air New Zealand flights (status, gates, delays)

Once a schedule is in hand, you enhance it with live status. This is where you surface whether an Air New Zealand flight into or out of SIN is still “scheduled,” “en-route,” “landed,” or otherwise updated with actual/estimated times, plus terminals and gates.

Official Real-time Flight Tracking JSON you’ll use

{
"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 interpret for NZ + SIN:

• flight.iata corresponds to the commercial flight designator. For Air New Zealand, look for values starting with “NZ” (e.g., NZ281). Filter results to include those where departure.airport == "SIN" or arrival.airport == "SIN".
• flight.status is the core state to show users (“scheduled,” “en-route,” “landed,” and other operational states where provided). If a flight is cancelled or diverted, reflect that status prominently and adjust notifications accordingly.
• departure.actual vs. departure.scheduled lets you compute departure delays. Similarly, arrival.estimated vs. arrival.scheduled helps you show ETA deltas.
• terminal and gate at both ends should override any earlier schedule info and power airport display signage.
• position fields enable map rendering for en-route NZ flights headed to/from SIN. Latitude/longitude are WGS84, altitude is typically in feet, speed in knots, and heading in degrees.

End-to-end example: fetch NZ schedules, filter to SIN, then overlay status

Below is a JavaScript example that requests Air New Zealand schedules and prepares a data model appropriate for a SIN-focused board. In production, you would then enrich each result with live status (from the real-time category) keyed by airline + number and airports.

async function fetchNZSchedulesAtSIN() {
const url = "https://api.goflightlabs.com/flights-schedules?iataCode=NZ&type=airline";
const res = await fetch(url, {
headers: { "apikey": "YOUR_API_KEY" }
});
if (!res.ok) throw new Error("Schedules request failed: " + res.status);
const json = await res.json();

const schedules = (json.data && json.data.schedules) || [];
// Keep flights that depart from or arrive into SIN
const sinSchedules = schedules.filter(s =>
(s.departure && s.departure.airport === "SIN") ||
(s.arrival && s.arrival.airport === "SIN")
);

// Normalize a minimal model for your board
return sinSchedules.map(s => ({
airlineIata: s.airline && s.airline.iata,
flightNumber: s.flight_number,
depAirport: s.departure && s.departure.airport,
depTimeUtc: s.departure && s.departure.scheduled,
depTerminal: s.departure && s.departure.terminal,
arrAirport: s.arrival && s.arrival.airport,
arrTimeUtc: s.arrival && s.arrival.scheduled,
arrTerminal: s.arrival && s.arrival.terminal
}));
}

// Example usage:
fetchNZSchedulesAtSIN()
.then(list => {
// Render list; next step: call your live-status function to overlay status/gates per flight
console.log("Air New Zealand schedules touching SIN:", list);
})
.catch(err => console.error(err));

Implementation guidance:

• Time zones: Treat fields ending with “Z” as UTC. Convert to local airport time for display (SIN is typically Asia/Singapore).
• Matching with live status: Join on airline IATA + flight number and date, then merge terminal/gate/status/actual times from the live endpoint to supersede schedule values.
• Caching: Cache schedule responses for 5–15 minutes. Cache live status for 15–30 seconds during critical phases (departure/arrival windows) and up to 2–5 minutes otherwise.

Practical use cases tied to NZ + SIN

1) Flight status pages for NZ operations at SIN

• Fields: flight.status, departure.actual, arrival.estimated, terminal, gate.
• Flow: show scheduled times from schedules; as live data arrives, update with actual/estimated times and gates. Display status prominently to reduce traveler uncertainty.

2) Delay monitoring and alerting for NZ flights into/out of SIN

• Fields: status “en-route,” “landed,” etc.; departure.actual vs. departure.scheduled; arrival.estimated vs. arrival.scheduled.
• Flow: compute mins delayed = (actual - scheduled) or (estimated - scheduled). Fire alerts when thresholds exceed your SLA. Optionally incorporate “Delay Predictions” for pre-departure risk flags.

3) Route analysis for NZ network segments that touch SIN

• Fields: airline.iata from schedules; route endpoints from the Routes category.
• Flow: confirm which NZ city-pairs include SIN for planning, and enrich with historical timings to guide connection buffers in corporate travel apps.

Airport context: SIN metadata you’ll reference

You’ll often need airport metadata (IATA, timezone, terminals). The Airport Information category gives structured details you can cache for UI rendering or validations. Below is the official structure example; adapt your logic for SIN specifically where returned by the API.

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

Guidance:

• Timezone: Use the airport’s timezone for local boards, but keep UTC internally for calculations and data joins.
• Terminals array: Useful for validation and UI lists when schedules or live endpoints return terminal identifiers.

Handling cancellations, diversions, and codeshares

• Status: When a flight is cancelled or diverted, the real-time status field will indicate this. Reflect the state unambiguously and suppress countdown timers to offload user support.
• Gates/terminals: If a schedule lists a terminal but live data later shows a different one, prefer live data. Maintain a change log for notifications.
• Codeshares: You may see multiple flight numbers for the same movement. Normalize by operational carrier + movement to avoid duplicates on boards and in analytics.

Pagination, polling, and rate control

• Pagination: When loading full-day schedules for NZ at SIN, use the schedules endpoint’s pagination controls as documented. Fetch and aggregate pages server-side, not in the browser, to avoid partial boards and to centralize caching.
• Polling cadence: For upcoming departures/arrivals (T-90 to T+60 minutes), poll live status every 30–60 seconds. Outside that window, 2–5 minute intervals are usually sufficient.
• Caching strategy: Cache static references (airports, routes) for hours to days; cache schedules for minutes; cache live status for tens of seconds during critical periods.

Error handling and resilience

• Fallbacks: If live status temporarily fails, display schedule times with a “Live updates unavailable” banner. Merge back in when the next successful poll arrives.
• Time normalization: Always parse ISO-8601 UTC times and immediately convert to a stable internal format before calculations.
• Partial data: Not all records have gates or terminals. Code defensively: check for field existence before rendering.

Getting started and environment setup

• Sign up for an API key: use the 7-day or 50-request trial to prototype, or the Starter plan at $24.99/month when you’re ready to ship.
• Test interactively via the MCP API console to validate your NZ + SIN queries before wiring them into your app.
• Read the parameter and pagination details in the Documentation. When in doubt, keep requests minimal and filter results client-side.
• Explore overall product info at www.goflightlabs.com and confirm endpoint availability for your region and stack.

Comparison: choosing the right FlightLabs category for the task

Below is a concise comparison focused on building an Air New Zealand board for SIN. It’s not a competitive benchmark; it’s a way to select the right FlightLabs capability for each job.

Putting it together for production

• Backend-first aggregation: Call schedules server-side, persist for minutes, and expose a low-latency endpoint to your frontend. Maintain a separate live-status poller keyed by NZ flight numbers with SIN as origin/destination.
• State model: Keep both schedule and live layers. For each NZ flight at SIN, display schedule by default and overwrite fields when live data arrives. Record last-updated timestamps per field.
• Resilience: Add circuit breakers and retries for upstream calls. On errors, return cached data (stale-while-revalidate) if it is not too old for your SLA.
• Observability: Log status transitions (scheduled → departed → en-route → landed/cancelled/diverted) to power alerting and improve UX around critical changes.

FAQ

How do I authenticate my requests?
FlightLabs uses an API key. Include your key as shown in the examples and confirm header/parameter details in the Documentation.

What time zone are schedule and status times in?
Times in the samples are UTC (noted by the trailing “Z”). Convert to local airport time (e.g., Asia/Singapore for SIN) for display. Keep UTC internally for stable comparisons and joins.

How frequently should I poll live data?
For NZ flights around departure or arrival, 30–60 seconds is typical. Outside those windows, 2–5 minutes is usually sufficient. Always respect caching headers and your plan’s request limits.

How do I handle pagination for schedules?
Use the pagination parameters described in the API docs when requesting large result sets (e.g., full-day NZ schedules). Aggregate server-side and return a consolidated view to clients.

Can I test queries before coding?
Yes. Use the MCP console to prototype requests, then copy working queries into your app.

Start building your Air New Zealand + SIN integration in minutes. Get your API key at Register, explore endpoint details in the Documentation, and learn more about the platform at www.goflightlabs.com.