Track Flight Delays for TruJet via Flight Delay API

You need a reliable way to detect and act on delays affecting TruJet (IATA: 2T) so your app can update ETAs, notify travelers, and keep operations on schedule. By the end of this guide, you’ll be able to query FlightLabs for TruJet delay signals, interpret the timing fields that matter, trigger alerts when a delay crosses a threshold, and decide how often to poll and cache results for efficient, accurate updates.

TruJet (IATA: 2T) and what “delay” really means in your integration

TruJet is an airline identified by IATA code 2T. When you’re coding for delays, what you actually need are consistent timing signals (scheduled, actual, estimated) and a flight status you can trust. With FlightLabs, you can combine delay predictions with real-time updates to understand whether a TruJet flight is late, by how much, and what that implies for passengers, gates, and connections.

In practice, developers typically use two complementary data sources to manage “delay”:

• Real-time status and timestamps to quantify departure/arrival slippage from schedule.
• Delay predictions to anticipate issues earlier and prioritize intervention.

We’ll show how to work with both, anchored specifically to TruJet (2T), using only the documented endpoints and response fields below. If you need an API key, get one at Register. You can also explore the platform at MCP and browse the Documentation.

The delay predictions endpoint you’ll call for TruJet

To monitor potential delays for TruJet, you’ll use the Flight Delay Predictions endpoint. This provides predictive signals that you can pair with live tracking. Because this article uses only the documented endpoints and fields here, the example call below demonstrates how to invoke the endpoint with your API key. Apply airline filtering and business logic on your side for TruJet’s IATA code 2T.

curl request to the Flight Delay Predictions endpoint

curl -G "https://www.goflightlabs.com/flight-delay" \
--data-urlencode "api_key=YOUR_API_KEY"

Notes:

• Replace YOUR_API_KEY with your FlightLabs key. If you don’t have one, visit www.goflightlabs.com to learn more and Register for access.
• When processing the response, filter to TruJet (IATA 2T) in your application. If you need additional filter parameters, check the Documentation.

Official response example and the fields you’ll actually use

The following official sample shows a live flight response structure with fields you can use to quantify delays, such as status, departure.scheduled vs departure.actual, and arrival.scheduled vs arrival.estimated. While your delay predictions response may focus on predictive signals, in production you’ll often pair predictions with live tracking to calculate the precise current delay and surface actionable details (terminals, gates).

{
"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 use these fields for TruJet delay handling:

• flight.status: Combine this status with prediction results to decide if you should notify users now or continue monitoring.
• departure.scheduled vs departure.actual: The difference is your actual departure delay once the aircraft pushes back. Keep in UTC for comparisons.
• arrival.scheduled vs arrival.estimated: The difference gives you the current arrival delay, which is usually what end users care about most once airborne.
• departure.terminal/gate and arrival.terminal/gate: Surface operational impacts alongside your delay message for a complete UX.

All timestamps are ISO 8601 with a “Z” suffix in the example, indicating UTC. In your UI, convert to local time zones for airports when needed, but do computations in UTC to avoid DST or offset confusion.

End-to-end example: fetching data and alerting on a delay threshold

Below is a JavaScript example that fetches live flight data, calculates delay from scheduled vs estimated/actual times, and emits an alert when the delay crosses a threshold. In your TruJet workflow, you can run this after reading prediction signals from the Flight Delay endpoint to either pre-warn or confirm live impact.

Step 1: Fetch real-time data and compute delay

/**
* Node.js example using fetch (Node 18+ or add node-fetch polyfill).
* This example computes delay from real-time fields:
* - departure.scheduled vs departure.actual
* - arrival.scheduled vs arrival.estimated
* Then emits an alert if delay exceeds a threshold.
*
* Filter to TruJet (IATA: 2T) using your own logic based on fields available
* in your real-time and schedule queries.
*/

const endpoint = "https://www.goflightlabs.com/real-time";
const apiKey = process.env.FLIGHTLABS_API_KEY || "YOUR_API_KEY";
const delayThresholdMinutes = 15; // change per your SLA

// Utility to compute difference in minutes between two ISO timestamps (UTC)
function diffMinutes(isoA, isoB) {
if (!isoA || !isoB) return null;
const a = Date.parse(isoA);
const b = Date.parse(isoB);
if (Number.isNaN(a) || Number.isNaN(b)) return null;
return Math.round((b - a) / 60000);
}

async function getLiveDelayAndAlert() {
const url = new URL(endpoint);
url.searchParams.set("api_key", apiKey);

const res = await fetch(url, { method: "GET" });
if (!res.ok) {
console.error("API error:", res.status, await res.text());
return;
}

const json = await res.json();

// Expect structure similar to the official sample:
// { success: true, data: { flight: { ... } } }
const flight = json?.data?.flight;
if (!flight) {
console.warn("No flight object in response");
return;
}

// Optional: Filter for TruJet (2T) if flight.iata or airline data is available in your response.
// For example, if your integration knows the flight IATA format includes airline code,
// ensure it matches 2T-* (apply your own logic based on your data feed).

const dep = flight.departure || {};
const arr = flight.arrival || {};

// Compute departure delay if we have 'actual' vs 'scheduled'
const departureDelayMin = diffMinutes(dep.scheduled, dep.actual);

// Compute arrival delay if we have 'estimated' vs 'scheduled'
const arrivalDelayMin = diffMinutes(arr.scheduled, arr.estimated);

// Choose a single value to alert on; prioritize arrival delay if known
const effectiveDelayMin = arrivalDelayMin ?? departureDelayMin;

if (effectiveDelayMin != null && effectiveDelayMin >= delayThresholdMinutes) {
const flightLabel = flight.iata || flight.icao || flight.number || "Flight";
const airportPair = `${dep.airport || "DEP"} → ${arr.airport || "ARR"}`;
const gateInfo = [
dep.terminal ? `Dep T${dep.terminal}` : null,
dep.gate ? `Gate ${dep.gate}` : null,
arr.terminal ? `Arr T${arr.terminal}` : null,
arr.gate ? `Gate ${arr.gate}` : null
].filter(Boolean).join(" · ");

// Emit your alert (log, webhook, push, etc.)
console.log(`[ALERT] ${flightLabel} ${airportPair} delayed ${effectiveDelayMin} min. ${gateInfo}`);
} else {
console.log("No delay above threshold or insufficient timing data.");
}
}

getLiveDelayAndAlert().catch(console.error);

Step 2: Combine with predictions

To anticipate issues earlier, call the Flight Delay Predictions endpoint before you fetch live data. Use the predictive result to prioritize which TruJet flights you should poll more frequently via real-time tracking. This avoids constant polling of every flight and keeps your latency budget in check. For the predictions response schema and filters, see the Documentation.

curl examples you can copy-paste

1) Flight Delay Predictions (for TruJet prioritization)

curl -G "https://www.goflightlabs.com/flight-delay" \
--data-urlencode "api_key=YOUR_API_KEY"

Process the JSON, filter to TruJet (2T) on your side, and enqueue the riskiest flights for more frequent live polling.

2) Real-time Tracking (to confirm actual or estimated delay)

curl -G "https://www.goflightlabs.com/real-time" \
--data-urlencode "api_key=YOUR_API_KEY"

From this response, read departure.scheduled vs departure.actual and arrival.scheduled vs arrival.estimated to compute current delay minutes. Use flight.status to augment your alerts and show context to users.

How to think about polling, caching, and time zones

Time zones: Treat all timing math in UTC. The example timestamps include “Z”, which denotes UTC. Convert to local airport time zones only for display. FlightLabs also provides airport time zone context via the Airport Information endpoint, if you need to render local times consistently.

Polling cadence:

• Predictions: Poll less frequently (e.g., every 10–15 minutes) to build a queue of TruJet flights likely to be delayed. Adjust to your plan and latency needs.
• Real-time confirmation: Poll prioritized flights more often, e.g., every 30–60 seconds around departure and arrival windows, backing off to 2–5 minutes in cruise.
• Event-based backoff: When a flight arrives or is no longer relevant, stop polling. Cache final state for your history view.

Caching:

• Short-term cache (15–60 seconds) for real-time fields to minimize bursts and smooth client updates.
• Longer cache (5–15 minutes) for schedule baselines; schedules don’t change often but are needed to compute delays reliably.

Error handling and retries: If an API call fails, retry with exponential backoff and respect your service’s rate and quota constraints. If a field is missing (e.g., estimated arrival not yet published), defer your alert until the field is available or fall back to a conservative estimate.

Handling cancelled, diverted, and irregular operations

In irregular operations, focus on the status field and any available timestamps. If a flight won’t depart, departure.actual won’t appear; rely on status and any terminal/gate changes to inform users. For diversions, track arrival fields for the new airport once available. If you see a status indicating a non-standard event and no reliable estimated times yet, suppress numerical delay statements and present a clear operational message instead.

Codeshares: When multiple marketing carriers are involved, align updates to the operating flight’s live signals so you don’t double-alert. If you aggregate schedules, de-duplicate codeshared entries before calculation to avoid inflated counts or duplicate push notifications.

Comparing endpoints you’ll use for TruJet delay monitoring

Here’s how the core endpoints play together for a TruJet-focused delay workflow. Use them in combination rather than choosing only one.

Pagination for schedules and efficient TruJet filtering

When loading multiple TruJet flights, load schedules in pages and cache them. The schedules sample shows:

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

Filter schedules by airline.iata in your application to isolate TruJet (2T). When combining schedules with predictions and live tracking, maintain a keyed store (e.g., by flight number and date) so you can join the three data sources quickly. Apply pagination parameters as documented and store cursors or page numbers for repeatable loads.

Practical implementation notes that save time

• Units and coordinates: Position fields (latitude, longitude, altitude, speed, heading) are standard aviation units (e.g., altitude in feet, speed in knots per the sample context). If you surface maps, cache the last received position to avoid map jitter between polls.
• Clock edges: Around pushback or touchdown, expect short-lived mismatches between estimated and actual times. Debounce alerts for a few seconds to avoid flipping states in your UI.
• Gate and terminal changes: When a delay is detected, also show the current terminal/gate from the response so users know where to go next.
• Server-side filtering: Even if the API supports filters, filter to TruJet and the routes you care about server-side too, keeping your client payloads small.
• Fallback behavior: If a field is missing (e.g., estimated arrival not yet set), show a “Monitoring” state and re-check soon instead of declaring “on-time” prematurely.

Balanced view: where each capability fits for TruJet delay use cases

• Delay predictions help you get ahead of problems. Use them to triage TruJet flights and schedule more frequent polls only for high-risk flights.
• Real-time data confirms the operational truth-on-the-ground with timestamps and gates, which is what you’ll display to users and use to compute actual delay minutes.
• Schedules define the baseline. Cache them and compare real-time or predicted times against the schedule to quantify any slippage.
• History lets you refine thresholds over time. If you see certain TruJet city-pairs repeatedly slip by small margins, adjust your alert threshold to reduce noise.

FAQ

• How do I filter results to TruJet (IATA: 2T)?
  Use airline fields in your responses (e.g., airline.iata in schedules) to include only items where iata is 2T. For other endpoints, apply filtering in your application logic based on the identifiers you have. Consult the Documentation for endpoint-specific query filters.
• Which timestamps should I compare for delays?
  Compare departure.scheduled vs departure.actual for departure delay and arrival.scheduled vs arrival.estimated for arrival delay. Keep all math in UTC.
• How frequently should I poll?
  Poll delay predictions less frequently (e.g., 10–15 minutes) and increase real-time polling (30–60 seconds) only for TruJet flights flagged as high risk. Back off during cruise or after arrival.
• How do I handle cancellations or diversions?
  Rely on the status field and available timing changes. If a cancellation or diversion is indicated and estimates are missing, show a clear operational message instead of a numerical delay.
• Where do I find full schema details and filters?
  See the Documentation for endpoint-specific parameters and response structures.

Ready to ship TruJet delay monitoring with predictive signals and real-time confirmations? Get your key at Register and explore the platform at MCP. Build, test, and iterate against the endpoints above to provide timely, accurate TruJet delay updates in your apps and dashboards.