Track Flight Delays for Azur Air via Flight Delay API

You need reliable, programmatic visibility into delays affecting Azur Air (IATA: ZF) so you can alert travelers, update displays, or trigger downstream workflows. By the end of this guide you’ll query FlightLabs endpoints, read the delay-related fields that matter, compare your options for detecting and predicting delays, and implement a simple alert that fires when an Azur Air flight’s delay exceeds a threshold.

Azur Air (IATA: ZF) and where delay signals live in FlightLabs

Azur Air operates charter and leisure flights under the IATA code ZF. To monitor delays for this airline end-to-end, you can combine two categories of FlightLabs endpoints:

• Operational status and timing deltas from real-time flight tracking, which include scheduled, actual, and estimated timestamps for departures and arrivals.
• Delay predictions, which provide a forward-looking signal you can incorporate into pre-departure notifications and staffing/logistics decisions.

Below we focus on how to extract delay information that’s directly actionable for Azur Air from the available response fields, then compare the real-time and prediction approaches so you can choose the right fit for your workflow.

The endpoints you’ll use to monitor ZF delays

All endpoints are RESTful and return JSON. You can sign up for an API key on goflightlabs.com and manage access via the MCP.

• Real-time Flight Tracking: https://www.goflightlabs.com/real-time
• Flight Delay Predictions: https://www.goflightlabs.com/flight-delay
• Flight Schedules (optional for planning windows): https://www.goflightlabs.com/flights-schedules
• Flight History (optional for post-op analytics): https://www.goflightlabs.com/flights-history

Even without a dedicated “delay minutes” field, you can compute effective delays from real-time status by comparing scheduled vs. actual (or estimated) timestamps in UTC. Delay predictions complement these with probabilistic signals before pushback.

Requesting operational timing for ZF and deriving delay

Below is a complete curl request to the real-time endpoint. After retrieving live flights, filter by Azur Air using the IATA flight number prefix “ZF” (for example, ZF123) to scope to the airline. You can then compute delays by comparing the provided times.

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

Official sample response (structure you’ll parse for delay detection):

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

Fields that matter for delay monitoring and status handling:

• flight.status: operational state such as “en-route.” Use this to branch your logic for pre-departure vs. airborne vs. post-arrival cases. Treat unlisted states (e.g., cancelled or diverted) at a high level and fall back to status-driven flows.
• departure.scheduled and departure.actual: both in UTC. departure.actual - departure.scheduled gives departure delay in minutes (positive values = late). For pre-departure flights, if actual is not present, compare estimated vs. scheduled when available.
• arrival.scheduled and arrival.estimated: estimated - scheduled gives projected arrival delay in minutes. Once arrival.actual is available (not shown in this sample), switch to actual - scheduled for final delay.
• departure.terminal/gate and arrival.terminal/gate: persist these for passenger messaging and to detect operational changes that often correlate with delays.

To scope this to Azur Air (ZF), filter by flight.iata starting with “ZF” (e.g., ZFxxx). If your integration fetches multiple flights per request, apply this filter client-side before computing delays.

JavaScript example: alert when any ZF delay exceeds a threshold

This example fetches real-time data, filters for Azur Air by IATA prefix, computes the larger of departure or arrival delay, and triggers a handler when the delay exceeds a threshold (in minutes). All timestamps are in UTC, so compute differences using Date objects without converting to local time.

async function fetchDelaysForAzurAir() {
const endpoint = "https://www.goflightlabs.com/real-time?api_key=YOUR_API_KEY";

const res = await fetch(endpoint, { method: "GET" });
if (!res.ok) throw new Error("Network error: " + res.status);
const payload = await res.json();

// Depending on your plan and request, you might receive one flight object or a list.
// The official sample shows a single flight in data.flight.
const normalizeToArray = (data) => {
if (!data) return [];
if (Array.isArray(data)) return data;
return [data]; // treat single object as array of one
};

const nowFlights = normalizeToArray(payload?.data?.flight);

// Keep only Azur Air (IATA code "ZF") flights.
const zfFlights = nowFlights.filter(f => typeof f?.iata === "string" && f.iata.startsWith("ZF"));

// Utility to compute delay in minutes between two ISO timestamps (both UTC).
const delayMinutes = (actualOrEstimated, scheduled) => {
if (!actualOrEstimated || !scheduled) return 0;
const a = new Date(actualOrEstimated).getTime();
const s = new Date(scheduled).getTime();
if (Number.isNaN(a) || Number.isNaN(s)) return 0;
return Math.round((a - s) / 60000);
};

const DELAY_THRESHOLD_MIN = 15;

const alerts = [];
for (const f of zfFlights) {
const depSched = f?.departure?.scheduled;
const depActualOrEst = f?.departure?.actual || f?.departure?.estimated;
const arrSched = f?.arrival?.scheduled;
const arrActualOrEst = f?.arrival?.actual || f?.arrival?.estimated;

const depDelay = delayMinutes(depActualOrEst, depSched);
const arrDelay = delayMinutes(arrActualOrEst, arrSched);
const worstDelay = Math.max(depDelay, arrDelay);

if (worstDelay >= DELAY_THRESHOLD_MIN) {
alerts.push({
flight: f?.iata || f?.icao || f?.number,
status: f?.status,
dep: {
airport: f?.departure?.airport,
scheduled: depSched,
actualOrEstimated: depActualOrEst,
terminal: f?.departure?.terminal,
gate: f?.departure?.gate,
delayMin: depDelay
},
arr: {
airport: f?.arrival?.airport,
scheduled: arrSched,
actualOrEstimated: arrActualOrEst,
terminal: f?.arrival?.terminal,
gate: f?.arrival?.gate,
delayMin: arrDelay
},
worstDelayMin: worstDelay
});
}
}

return alerts;
}

// Example usage: poll periodically
(async () => {
try {
const alerts = await fetchDelaysForAzurAir();
for (const a of alerts) {
console.log(
`[DELAY ALERT] ${a.flight} status=${a.status} worstDelay=${a.worstDelayMin} min ` +
`(DEP ${a.dep.airport} +${a.dep.delayMin}m, ARR ${a.arr.airport} +${a.arr.delayMin}m)`
);
// TODO: send to Slack, email, or webhook
}
} catch (err) {
console.error("Error fetching delays:", err);
}
})();

How to combine real-time status with delay predictions for ZF

FlightLabs also exposes delay predictions at /flight-delay. Use it to assess risk before pushback, then transition to real-time operations once a flight is close to departure or airborne. When predictions indicate high risk, proactively lengthen your polling interval for that flight’s status to tighten alerting windows.

What to use when

• Before departure (D-24h to D-1h): Call Flight Delay Predictions to gauge risk; complement with Flight Schedules for planned timings.
• At/after scheduled departure time: Prioritize Real-time Flight Tracking for definitive actual vs. scheduled deltas.
• For post-op reporting: Use Flight History to compute realized delay statistics and SLA metrics by route or day.

Comparison: endpoints you can mix for Azur Air delay use cases

Below is a technical comparison across several FlightLabs endpoints frequently combined for delay monitoring and alerting for Azur Air.

Understanding times, status, and special cases

Time zones: FlightLabs timestamps in the examples are UTC (Z-suffixed ISO 8601). Do all arithmetic in UTC. Only convert to local time for end-user display, not for your calculations, to avoid DST and timezone errors.

Status-driven logic: When status indicates phases like scheduled, active, en-route, landed, etc., choose which fields to compare:

• Scheduled or check-in open: Compare estimated vs. scheduled to anticipate delays.
• Departed/en-route: Compare actual vs. scheduled for departure delay; estimated vs. scheduled for arrival delay.
• Landed: Prefer arrival.actual vs. arrival.scheduled (when available) for final arrival delay.

Cancelled or diverted: Treat these as terminal states. Because specific strings aren’t listed here, implement a generic “non-standard completion” branch keyed off flight.status. Suppress standard delay math and surface a structured event (e.g., { type: "cancelled" | "diverted" }).

Polling frequency, caching strategy, and backoff

Polling for live ZF flights:

• Pre-departure window: 2–5 minute intervals are typically sufficient, increasing frequency as scheduled departure approaches.
• At or after scheduled departure: shorten to 30–60 seconds during the critical window while pushback and airborne times are changing.
• En-route: 2–5 minutes is usually enough unless you need tight gate-ready predictions.

Adaptive backoff: If a flight is significantly delayed on departure (large positive delta), you can slightly relax polling until a new estimate arrives, then tighten again near wheels-down.

Caching: Cache immutable data like schedules and static airline/airport info for hours or longer. For live data, respect cache lifetimes of well under 5 minutes and vary by phase of flight. Use an in-memory cache keyed by flight.iata or flight.icao to de-duplicate alerts (emit only on state change or when delay crosses a threshold).

Working with terminals, gates, and codeshares

Terminals and gates can change during irregular operations. Monitor departure.terminal/gate and arrival.terminal/gate for updates alongside your delay deltas. Codeshares aren’t shown in the provided samples; when present in your plan, normalize to the operating carrier’s ZF flight where possible, and propagate alerts to all shared numbers in your UI.

Scheduling windows and pagination

The schedules endpoint response shows data.schedules as an array. When fetching schedules for Azur Air across multiple airports or days, expect pagination controls in your plan and implement a loop until you exhaust pages. Store schedules keyed by flight_number plus date and reconcile with real-time data as flights approach operation.

Airport and airline context for richer notifications

To improve traveler messages and operational dashboards, enrich ZF delay alerts with airport details (e.g., terminal lists and time zones) and airline display names from reference endpoints. The airport sample includes fields like timezone, terminals, and even basic weather context—useful for annotating alerts when deviations are weather-related.

Putting it together: a practical flow for Azur Air

1. Ingest Azur Air’s planned schedule for the operating day from Flight Schedules and cache it keyed by date/flight.
2. From D-24h onward, query Flight Delay Predictions periodically to identify high-risk ZF flights and flag them for closer monitoring.
3. As flights approach departure time, poll Real-time Flight Tracking, filter to ZF by flight.iata prefix, and compute:
   • Departure delay = (departure.actual or estimated) – departure.scheduled
   • Arrival delay = (arrival.actual or estimated) – arrival.scheduled
4. When delay thresholds are crossed, emit alerts with current terminal/gate and a UTC timestamp. Suppress duplicates until a state or field changes.
5. Post-op, record realized delays via Flight History for analytics and tuning of thresholds by route and time-of-day.

Additional examples you can adapt

Example: extract schedule baseline for deltas

Use planned times from schedules for baseline comparisons; example structure you’ll see in responses:

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

For Azur Air, substitute your schedule ingestion logic to filter by airline.iata = "ZF" when your plan returns this field. Persist the scheduled timestamps as your delay baseline.

Error handling, reliability, and logging

• HTTP errors: Implement retries with jitter and a circuit breaker for transient issues.
• Schema tolerance: Optional fields like actual or estimated may be absent depending on flight phase; always guard reads.
• Clock skew: Rely on server timestamps; avoid mixing client timestamps into delay math beyond logging collection time.
• Idempotency for alerts: Use a composite key (flight ID + field hash + threshold bin) to prevent duplicate dispatches.

Where to go next

Explore the Documentation for up-to-date field coverage, authentication details, and endpoint nuances. Create and manage your key in the MCP, and review response shapes you’ll encounter in your plan.

If you haven’t yet, get your API key now: Register. You can also learn more at www.goflightlabs.com.

FAQ

• How do I filter specifically for Azur Air flights? Filter by the IATA flight number prefix “ZF” in flight.iata (e.g., ZF123). If your plan returns airline metadata, also match airline.iata = "ZF".
• Which timestamps should I compare to compute delays? Use UTC fields: for departures, compare departure.actual (or estimated) to departure.scheduled; for arrivals, compare arrival.actual (or estimated) to arrival.scheduled.
• How often should I poll for live delay updates? 2–5 minutes pre-departure, 30–60 seconds around scheduled departure, and 2–5 minutes en-route. Adapt based on prediction risk and operational needs.
• What about cancelled or diverted flights? Treat these as special terminal states based on flight.status. Skip standard delay math and emit a structured event with the latest known terminal/gate and timestamps.
• Can I see gates and terminals for messaging? Yes. Use departure.terminal/gate and arrival.terminal/gate from real-time responses; changes often correlate with operational disruptions and are useful for traveler communications.

Build Azur Air delay monitoring into your app in minutes. Read the Documentation, get an API key via Register, and manage access in the MCP. For an overview of capabilities, visit goflightlabs.com.