Track Sri Lankan Airlines Flights Live with Our Flight Info By Flight Number API (LIS).

You need to show real-time, trustworthy status for SriLankan Airlines flights in your app—without hand-stitching dozens of data feeds. By the end of this guide, you’ll query FlightLabs by flight number for SriLankan Airlines (IATA: UL), interpret the JSON for live status, terminals, gates, and times, and implement a clean polling-and-caching loop that handles delays, cancellations, and diversions.

SriLankan Airlines at a glance for implementers

SriLankan Airlines (IATA: UL) is the flag carrier of Sri Lanka. Its main hub is Bandaranaike International Airport near Colombo. For developers, the key anchor is the UL IATA code, which you’ll use with FlightLabs endpoints to fetch flight-specific data. This article focuses on pulling status by flight number and refreshing it for production use.

Choosing the right FlightLabs endpoints for UL flight tracking

FlightLabs provides multiple endpoints that are useful at different stages of a flight’s lifecycle. For SriLankan Airlines, most implementations combine at least two:

• Detailed Flight Info by Flight Number: returns the canonical, flight-number-centric view you’ll show to users.
• Real-time Flight Tracking: augments with live position and rolling status updates for in-progress flights.
• Flight Schedules: helps you prefill upcoming UL services and paginate across a date window.

Explore these endpoints in the Documentation, and obtain credentials via Register.

Call the Flight Info by Flight Number endpoint for a UL flight

The FlightLabs “Detailed Flight Info” endpoint is designed for single-flight queries. You’ll provide your API key and the target flight number (IATA format “UL123”). The example below demonstrates a straightforward GET query. Replace YOUR_API_KEY and the flight number as needed.

curl -G 'https://www.goflightlabs.com/flight-info-by-flight-number' \
--data-urlencode 'access_key=YOUR_API_KEY' \
--data-urlencode 'flight_iata=UL123'

Tips:

• Use the IATA number (e.g., UL503) to align with user expectations in consumer apps and corporate travel platforms.
• Cache the response for a short interval (30–60 seconds) to control API usage, then refresh during day-of-operation.
• For airport-specific views (e.g., Lisbon LIS), filter locally by departure.airport or arrival.airport once you have the JSON.

Understand the live tracking JSON fields (official sample)

Below is an official example of a real-time response structure returned by FlightLabs. Although the airline and flight number in this sample differ, the structure and key fields are representative of what you’ll work with for SriLankan Airlines (UL):

{
"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 notes you will likely use:

• flight.status: canonical high-level state such as scheduled, departed, en-route, landed, cancelled, or diverted.
• departure.scheduled and arrival.scheduled: ISO 8601 UTC times (Z). Store in UTC; format for users in local time.
• departure.actual and arrival.estimated: compare against scheduled to compute delay minutes.
• departure.terminal/gate and arrival.terminal/gate: render on your flight detail page and on-airport displays.
• position.*: visible only while en-route; display on a map and compute progress.

About delays and codeshares:

• Delays are typically derived by comparing timestamps, for example, actual minus scheduled for departure, or estimated minus scheduled for arrival. The difference in minutes is your delay metric.
• Codeshare relationships can affect what users search for. Your UI can display the UL flight number as the primary key while noting any partner numbers if present in the returned payload. If a codeshare indicator is not included in the object, consider exposing the operating vs. marketing carrier context in your UI at a higher level.

JavaScript example: refresh UL flight status and compute delays

This snippet queries the Flight Info by Flight Number endpoint for SriLankan flights (using a UL flight number), computes arrival and departure delays, and normalizes times to UTC. It also demonstrates a simple polling loop you can adapt to your app.

async function fetchFlightInfoByNumber(flightIata) {
const params = new URLSearchParams({
access_key: process.env.FLIGHTLABS_KEY || 'YOUR_API_KEY',
flight_iata: flightIata
});

const url = `https://www.goflightlabs.com/flight-info-by-flight-number?${params.toString()}`;
const res = await fetch(url, { timeout: 10000 });
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const json = await res.json();
if (!json.success) throw new Error('API call unsuccessful');
return json.data.flight;
}

// Utility: parse ISO time safely and compute minutes diff (b - a)
function diffMinutes(aIso, bIso) {
if (!aIso || !bIso) return null;
const a = new Date(aIso).getTime();
const b = new Date(bIso).getTime();
return Math.round((b - a) / 60000);
}

// Render minimal status payload for your UI or logs
function summarizeFlight(f) {
const dep = f.departure || {};
const arr = f.arrival || {};
const summary = {
flight_iata: f.iata,
status: f.status,
departure: {
airport: dep.airport,
scheduled_utc: dep.scheduled,
actual_utc: dep.actual,
terminal: dep.terminal,
gate: dep.gate,
delay_departure_min: diffMinutes(dep.scheduled, dep.actual)
},
arrival: {
airport: arr.airport,
scheduled_utc: arr.scheduled,
estimated_utc: arr.estimated,
terminal: arr.terminal,
gate: arr.gate,
delay_arrival_min: diffMinutes(arr.scheduled, arr.estimated)
},
position: f.position || null
};
return summary;
}

// Example: poll every 45 seconds during day-of-flight
async function trackSriLankanFlight() {
const flightIata = 'UL503'; // Example UL flight number (replace as needed)
const pollMs = 45000;
let stop = false;

const interval = setInterval(async () => {
if (stop) return;
try {
const flight = await fetchFlightInfoByNumber(flightIata);
const s = summarizeFlight(flight);
console.log(new Date().toISOString(), JSON.stringify(s));

// Exit conditions: flight is landed, cancelled, or diverted
if (['landed', 'cancelled', 'diverted'].includes((flight.status || '').toLowerCase())) {
stop = true;
clearInterval(interval);
}
} catch (err) {
// Backoff or log; avoid tight error loops
console.error('Fetch error:', err.message);
}
}, pollMs);
}

// Run the tracker (ensure FLIGHTLABS_KEY is set or replace YOUR_API_KEY above)
trackSriLankanFlight();

Production notes:

• Time handling: all examples show Z-suffixed UTC times. Convert to local airport time for displays, but store and compute in UTC to avoid DST pitfalls.
• Polling windowing: reduce or stop polling after a terminal state (landed/cancelled/diverted). Before departure, a 60–120s cadence is usually sufficient; while en-route, 30–60s gives responsive ETAs without excessive churn.
• Caching: introduce a per-flight short TTL cache (e.g., 30–60s) to coalesce duplicate requests from multiple clients.

How to handle cancelled and diverted UL flights

FlightLabs exposes a single status field that your logic can branch on. For cancellations:

• status = cancelled: stop location polling immediately, show the canceled state prominently, surface terminal/gate only if still relevant for passengers (e.g., to reach rebooking desks).
• Re-run the Flight Info endpoint occasionally to detect re-accommodation changes if your product needs to reflect them.

For diversions:

• status = diverted: the arrival.airport may reflect the diversion airport, and the estimated time may update. Keep your UI flexible for terminal/gate changes that can appear late.
• If you display maps, continue rendering position to show progress toward the new airport.

Airport-specific tracking example: focus on Lisbon (LIS)

When your UI is centered on Lisbon (LIS), filter your UL results locally by arrival.airport === "LIS" or departure.airport === "LIS" after calling the flight-by-number or schedules endpoints. For example:

• Pre-flight schedule view: use flights-schedules to discover UL services touching LIS for a given date, then render departure.scheduled and arrival.scheduled columns.
• Day-of-flight status: call flight-info-by-flight-number for the specific UL flight to LIS and refresh status, gate, and terminal in short intervals.
• En-route: if your LIS display includes progress bars or maps, combine flight info with real-time to show position and ETA changes in near real time.

Building three practical UL use cases

1) Flight status detail pages for UL flights

• Fields: flight.status, departure.scheduled/actual/terminal/gate, arrival.scheduled/estimated/terminal/gate.
• UX: show planned vs. current times; compute delay minutes; highlight gates as separate badges; always surface status in a label.
• When to update: 30–60s cadence; faster refresh near boarding and arrival.

2) Delay monitoring and alerts for operations

• Fields: departure.actual vs. scheduled and arrival.estimated vs. scheduled.
• Logic: raise alerts when delay exceeds thresholds (e.g., 15+ minutes) and suppress flapping by requiring two consecutive delayed reads before alerting.
• Output: Slack/Webhook events with flight.iata, latest delay minutes, and terminal/gate context.

3) Route analysis for UL services (e.g., to/from LIS)

• Fields: schedules[].flight_number, departure.scheduled, arrival.scheduled, aircraft.type.
• Approach: use the schedules endpoint to list planned services for a date window, aggregate by route, then join with day-of-flight status for realized vs. planned comparisons.
• Result: simple dashboards showing frequency and timing windows—helpful for planning airport staffing and connection guidance.

Production integration tips: polling, caching, and pagination

• Polling strategies:
  • Pre-departure: 60–120s intervals are generally adequate.
  • En-route: 30–60s to keep ETA fresh and maps smooth.
  • Terminal states (landed/cancelled/diverted): stop or slow to 10+ minutes for archival updates.
• Cache layering:
  • Edge cache per-flight TTL of 30–60s to eliminate thundering herds from multiple clients.
  • In-memory or Redis “hot set” for flights departing or arriving in the next 3 hours.
• Handling missing fields:
  • Not all flights will include terminal/gate or position. Build nullable-safe renderers.
  • Compute delays from available times if a dedicated delay field isn’t present.
• Pagination for schedules:
  • The schedules endpoint returns an array of schedules objects. For date ranges and airline-wide lists, expect pagination and plan to traverse pages as documented.
  • Store page cursors/markers where provided by the API, and cap total pages per run to avoid runaway jobs.

Airport, airline, and route context: what else you can join

For richer displays or analytics, combine the flight-by-number call with these reference resources:

• Airline Flights: list UL services for a day or a route, then hydrate each with detailed flight info as needed.
• Retrieve Routes: map which airports UL serves and prebuild route selectors for users.
• Flight History and Future Flights: pull historical vs. planned context for long-running dashboards and travel-planning features.

You can browse and test these endpoints in the MCP, then integrate them directly in your app.

Example: combine detailed info with real-time for live maps

For a SriLankan Airlines UL flight that’s currently en-route, call the flight-by-number endpoint for schedule, terminal, and gate details, and refresh the real-time endpoint to update position and ETA. Your UI can then:

• Display planned vs. estimated arrival with a colored delay indicator computed from scheduled vs. estimated times.
• Show an aircraft icon at position.latitude/longitude with heading, refreshing on the chosen cadence.
• Fall back to status and times when position is unavailable (e.g., ground operations or coverage gaps).

curl example for real-time updates

Use the real-time endpoint when your UL flight is airborne and you need live position. Replace YOUR_API_KEY and filter to the flight as documented in your workspace.

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

From the response, extract:

• flight.status for current phase.
• arrival.estimated to reflect the moving ETA.
• position.latitude/longitude/altitude/speed/heading for maps and progress indicators.

Operational guardrails

• Timeouts and retries: use per-request timeouts (e.g., 10 seconds) and exponential backoff on 5xx errors to avoid spiky traffic patterns.
• Idempotency: your GET requests are idempotent; when updating your own state store, guard against out-of-order arrivals with server timestamps if available.
• Status transitions: maintain a simple state machine (scheduled → departed → en-route → landed/cancelled/diverted) so your UI never regresses to an earlier phase.

Validate times and compute user-facing deltas

Since timestamps are ISO 8601 Z, keep calculations in UTC internally. For end users, display times in the local time zone of the departure or arrival airport. For delays:

• Departure delay: difference between departure.actual and departure.scheduled.
• Arrival delay: difference between arrival.estimated and arrival.scheduled.

If either timestamp is missing, show “On time” or “TBD” with a neutral state rather than assuming zero delay.

Security, keys, and environments

• Store your FlightLabs key in environment secrets, not in client-side code.
• Proxy requests through your backend to enforce quotas and add caching.
• Use separate keys/projects for staging and production to isolate traffic and debugging.

Get your API key via Register and start testing endpoints in the Documentation.

FAQ

• How often should I poll the API for a UL flight on day-of-operation? Pre-departure every 60–120 seconds, en-route every 30–60 seconds, and stop or slow dramatically once the flight reaches a terminal state (landed/cancelled/diverted).
• Are timestamps local or UTC? Timestamps in examples are ISO 8601 with a Z suffix, indicating UTC. Convert for the user’s locale at render time, but keep UTC internally.
• How do I compute delays if there is no explicit delay field? Subtract scheduled from actual (departure) or scheduled from estimated (arrival) to get delay minutes. If any time is missing, show “TBD”.
• What if a UL flight is diverted? The status will indicate diverted and arrival fields may change to the diversion airport and updated ETA. Continue polling to reflect changes and update the map position if shown.
• Can I list upcoming UL flights to/from LIS? Use the flights-schedules endpoint to discover planned services, then hydrate selected flights with detailed flight info by flight number for status and day-of-flight changes.

Ready to implement SriLankan Airlines flight tracking by number and ship it to production? Create your key using Register and start building with the Documentation. You can also test queries interactively in the MCP before integrating them into your app.