Track Aeromexico Flights Live with Our Flight Info By Flight Number API (MEL).
You need to display the live status of a specific Aeromexico flight by its flight number and keep that view fresh without overwhelming your servers or users. By the end of this guide you will query FlightLabs for Aeromexico (IATA: AM) flight details by flight number, parse the key status and timing fields, implement safe polling, and handle edge cases like cancellations and diversions.
Aeromexico (AM) at a glance
Aeromexico is Mexico’s flag carrier, operating globally under the IATA code AM. Its primary hub is Mexico City, Mexico. In this guide, we will query Aeromexico flights using AM flight numbers and build production-ready status handling around the FlightLabs flight info by flight number endpoint.
Endpoint: Detailed Flight Info by Flight Number
Use this endpoint to fetch a single flight’s live status and operational details by the airline’s flight number. It’s ideal for status pages, mobile notifications, and airport displays that start with a user-entered flight number (e.g., AM30).
Endpoint:
https://www.goflightlabs.com/flight-info-by-flight-number
Authentication: include your API key as documented by FlightLabs. Replace YOUR_API_KEY with your key.
curl -G https://www.goflightlabs.com/flight-info-by-flight-number \
--data-urlencode "api_key=YOUR_API_KEY" \
--data-urlencode "flight_iata=AM30"
Notes:
- Use the Aeromexico IATA flight designator (AM) followed by the numeric flight number: AM30, AM1, AM681, etc.
- Timestamps in examples are in UTC (ISO 8601 with a trailing Z). Convert to the user’s local time zone in your UI.
Example: Live Aeromexico flight response and key fields
The following response structure is illustrative and uses the documented field names. Values are realistic but for example purposes only.
{
"success": true,
"data": {
"flight": {
"iata": "AM30",
"icao": "AMX30",
"number": "30",
"status": "en-route",
"departure": {
"airport": "MEX",
"scheduled": "2024-03-20T15:25:00Z",
"actual": "2024-03-20T15:41:00Z",
"terminal": "2",
"gate": "S23"
},
"arrival": {
"airport": "JFK",
"scheduled": "2024-03-20T21:30:00Z",
"estimated": "2024-03-20T21:37:00Z",
"terminal": "1",
"gate": "7"
},
"position": {
"latitude": 27.05,
"longitude": -89.22,
"altitude": 36000,
"speed": 480,
"heading": 58
}
}
}
}
What to use:
- flight.status: Present to users as en-route, scheduled, landed, cancelled, diverted, etc.
- departure.scheduled and arrival.scheduled: Baseline times for delay calculations and schedule displays (UTC).
- departure.actual and arrival.estimated: Real-time operational times; compute delays by comparing to scheduled.
- departure.terminal/gate and arrival.terminal/gate: For signage and passenger wayfinding.
- position: Use when you need a live map track (lat, lon, altitude, speed, heading).
Codeshares: If your users search a marketed codeshare flight number, align on the operating carrier’s IATA and flight number whenever possible. If codeshare data is available in your plan, normalize display labels to the operating carrier and map equivalents to the same operational record. The exact representation of codeshares can vary; consult the documentation linked below.
Additional status edge cases (JSON examples)
Below are common real-world scenarios you should handle. These use only documented field names and show how values might look.
1) Cancelled flight
{
"success": true,
"data": {
"flight": {
"iata": "AM681",
"icao": "AMX681",
"number": "681",
"status": "cancelled",
"departure": {
"airport": "MEX",
"scheduled": "2024-03-20T09:00:00Z",
"terminal": "2",
"gate": "N14"
},
"arrival": {
"airport": "LAX",
"scheduled": "2024-03-20T13:15:00Z",
"terminal": "B",
"gate": "205"
}
}
}
}
UI behavior: Prominently show cancelled and remove live times. Offer rebooking logic in your app. Keep scheduled times for context.
2) Diverted flight
{
"success": true,
"data": {
"flight": {
"iata": "AM1",
"icao": "AMX1",
"number": "1",
"status": "diverted",
"departure": {
"airport": "MEX",
"scheduled": "2024-03-20T07:00:00Z",
"actual": "2024-03-20T07:18:00Z",
"terminal": "2",
"gate": "S10"
},
"arrival": {
"airport": "IAH",
"scheduled": "2024-03-20T11:40:00Z",
"estimated": "2024-03-20T11:20:00Z",
"terminal": "C"
},
"position": {
"latitude": 29.98,
"longitude": -95.34,
"altitude": 5000,
"speed": 200,
"heading": 170
}
}
}
}
UI behavior: Clearly indicate diverted and show the current arrival.airport. Gate might be missing or change quickly; avoid caching gate data too aggressively for diversions.
3) Landed with delay
{
"success": true,
"data": {
"flight": {
"iata": "AM402",
"icao": "AMX402",
"number": "402",
"status": "landed",
"departure": {
"airport": "GDL",
"scheduled": "2024-03-20T12:00:00Z",
"actual": "2024-03-20T12:28:00Z",
"terminal": "1",
"gate": "C8"
},
"arrival": {
"airport": "MEX",
"scheduled": "2024-03-20T13:25:00Z",
"estimated": "2024-03-20T13:47:00Z",
"terminal": "2",
"gate": "S7"
}
}
}
}
Delay calculation: departure delay = actual − scheduled; arrival delay = estimated/actual − scheduled. Always compute and store as minutes for UI sorting and analytics.
4) Schedule record for downstream planning
When you need planned times without live telemetry or when pre-populating UIs, call the schedules endpoint. Here is the documented structure applied to Aeromexico:
{
"success": true,
"data": {
"schedules": [
{
"flight_number": "AM30",
"departure": {
"airport": "MEX",
"scheduled": "2024-03-20T15:25:00Z",
"terminal": "2"
},
"arrival": {
"airport": "JFK",
"scheduled": "2024-03-20T21:30:00Z",
"terminal": "1"
},
"aircraft": {
"type": "Boeing 787-9",
"registration": "N123AM"
},
"airline": {
"name": "Aeromexico",
"iata": "AM"
}
}
]
}
}
Combine planned schedules with live status to show an initial board that upgrades to real-time as the departure date approaches.
Code sample: Refreshing an Aeromexico flight status by number
The snippet below fetches AM30 and refreshes the status periodically. It computes basic delays from scheduled versus actual/estimated times. Replace YOUR_API_KEY before running.
const API_BASE = "https://www.goflightlabs.com/flight-info-by-flight-number";
const API_KEY = "YOUR_API_KEY";
const FLIGHT_IATA = "AM30";
async function fetchFlight() {
const url = new URL(API_BASE);
url.searchParams.set("api_key", API_KEY);
url.searchParams.set("flight_iata", FLIGHT_IATA);
const res = await fetch(url.toString(), { method: "GET" });
if (!res.ok) throw new Error("HTTP " + res.status);
const json = await res.json();
if (!json.success || !json.data || !json.data.flight) throw new Error("No flight data");
const f = json.data.flight;
// Helper to compute delay in minutes (UTC strings or undefined)
const delayMins = (actualOrEstimated, scheduled) => {
if (!actualOrEstimated || !scheduled) return null;
const a = new Date(actualOrEstimated).getTime();
const s = new Date(scheduled).getTime();
return Math.round((a - s) / 60000);
};
const depDelay = delayMins(f.departure.actual, f.departure.scheduled);
const arrDelay = delayMins(f.arrival.estimated, f.arrival.scheduled);
return {
status: f.status,
flight_iata: f.iata,
dep_airport: f.departure.airport,
dep_scheduled_utc: f.departure.scheduled,
dep_actual_utc: f.departure.actual,
dep_terminal: f.departure.terminal,
dep_gate: f.departure.gate,
arr_airport: f.arrival.airport,
arr_scheduled_utc: f.arrival.scheduled,
arr_estimated_utc: f.arrival.estimated,
arr_terminal: f.arrival.terminal,
arr_gate: f.arrival.gate,
dep_delay_mins: depDelay,
arr_delay_mins: arrDelay,
position: f.position || null
};
}
async function startPolling(intervalMs = 45000) {
let lastStatus = null;
for (;;) {
try {
const data = await fetchFlight();
if (data.status !== lastStatus) {
console.log("Status change:", lastStatus, "→", data.status);
lastStatus = data.status;
}
console.log(JSON.stringify(data));
} catch (e) {
console.error("Fetch error:", e.message);
}
await new Promise(r => setTimeout(r, intervalMs));
}
}
// Kick off polling
startPolling(45000);
Implementation tips:
- Poll more frequently around departure and arrival (e.g., every 30–60 seconds), less frequently en-route (60–120 seconds).
- If you display a map, only update when position changes. Otherwise, render text updates on status/terminal/gate/time changes.
- Cache negative lookups (no data) for a short TTL to reduce retries on nonexistent flight numbers.
Polling, caching, cancellations, and diversions
Polling frequency: For a single AM flight, 30–60 seconds is practical during gate, pushback, takeoff, and arrival phases. If you are tracking many flights concurrently, stagger requests and enforce per-flight backoff when status is stable (e.g., en-route with unchanged ETA for 5 minutes).
Caching: Cache schedule metadata for a flight day (terminal labels, planned times) with a long TTL and overwrite it only when live fields appear. Cache dynamic fields (actual, estimated, gate, status) for short TTLs (tens of seconds). Gate and terminal values can change close to departure and arrival; avoid aggressive caching for those fields.
Cancelled handling: A cancelled status should disable live time computations and position visuals. Keep scheduled times for context and provide alternative options if your app supports rebooking. Do not attempt to resolve a new flight using the same number unless a subsequent API call returns a new record with a different date.
Diverted handling: Treat arrival.airport as authoritative for the diversion. Terminal/gate may be missing or provisional; display “TBD” gracefully. After a diversion, the original arrival airport may still be relevant for downstream logistics; store both the scheduled destination and the actual diversion destination for audit.
Error handling: Handle non-200 HTTP responses and missing data fields by showing a neutral state (“Data not available”) instead of stale values. Log errors with the requested flight number and timestamp to assist with support inquiries.
Use cases built on Aeromexico flight data
- Flight status pages and mobile push: Use flight.status, departure.actual, arrival.estimated, and gate/terminal fields to drive concise, phase-aware notifications (e.g., “Boarding at Gate S23,” “Taxiing,” “Arriving at T1 Gate 7”).
- Delay monitoring dashboard: Compute departure delay from actual versus scheduled and arrival delay from estimated versus scheduled. Sort Aeromexico flights by delay minutes and surface risk indicators to ops teams.
- Route-level planning and analysis: Combine the schedules endpoint (planned times) with observed statuses across dates to identify routes where terminal changes or seasonal timing shifts impact connections. Persist airport codes from departure.airport and arrival.airport for aggregation.
Comparing related FlightLabs endpoints for Aeromexico operations
These endpoints complement the flight-info-by-flight-number call when you need broader or deeper coverage around Aeromexico’s operations.
| Endpoint | Best for | Key fields | Typical polling/usage |
|---|---|---|---|
| https://www.goflightlabs.com/flight-info-by-flight-number | Single-flight status lookup by AM flight number | flight.status, departure/arrival times, terminals, gates, position | 30–120s per active flight; event-driven UI updates |
| https://www.goflightlabs.com/real-time | Live tracking and telemetry across many flights | flight.status, position (lat/lon/alt/speed/heading) | Map tiles and fleet overviews; 30–60s refresh windows |
| https://www.goflightlabs.com/flights-schedules | Planned times and resource planning | schedules[].departure/arrival.scheduled, terminals, aircraft | Daily prefetch with caching; paginate through date ranges |
| https://www.goflightlabs.com/flights-history | Back-testing ETAs and reliability patterns | Historical times and statuses | Batch pulls; aggregate by route/flight number |
| https://www.goflightlabs.com/flights-airline | Airline-level views (all AM flights in scope) | Multiple flights with per-flight status and times | Board-level dashboards; interval fetch and cache |
Time zones, UTC, and identifiers
- Timestamps are provided in UTC (ISO 8601 with Z). Convert to local time zones at render time and clearly label time zones for airports spanning DST changes.
- Airport fields use IATA codes (e.g., MEX, JFK). Store these as uppercase strings and validate against your airport reference data.
- Flight numbers appear in multiple forms: iata (AM30), icao (AMX30), and number (30). Use iata for user-facing lookups; icao helps disambiguate internally when needed.
- Aircraft details, when present (in schedules or other endpoints), can aid seat maps and equipment-specific rules in your app.
Production integration tips
- Backoff and jitter: When polling many Aeromexico flights, apply per-flight backoff and random jitter to avoid synchronized spikes.
- Idempotent updates: Compare last-seen times and gates before notifying users; push only on changes to reduce noise.
- Data consistency: Status transitions often proceed scheduled → active/boarding → departed → en-route → landed → arrived. Handle potential regressions gracefully (rare feed delays).
- Pagination: When consuming schedules across many days or routes, expect paginated results. Iterate until you have a complete set for your date window; cache pages to reduce re-fetches.
- Data retention: Store compact audit logs (status, ETA, gate changes) for post-event analysis and user support.
End-to-end example: Building an Aeromexico status widget
Here’s a minimal flow you can adapt for your app:
- User enters AM flight number (e.g., AM30) for today’s date.
- Call the flight info by flight number endpoint to get flight.status and times.
- Compute delays from scheduled vs. actual/estimated and render a sentence like “AM30 is en-route to JFK. ETA 21:37 UTC (7 min delay).”
- Refresh every 45 seconds until landed/cancelled; then relax polling to every few minutes or stop after a timeout.
- Store the final result with timestamps for analytics and customer support.
Where to go next
Explore the broader endpoints and field definitions in the FlightLabs documentation. When you are ready to build, get your credentials here: Get your FlightLabs API key.
FAQ
How often should I poll a single Aeromexico flight?
30–60 seconds near departure and arrival, and 60–120 seconds while en-route. Back off once a flight is landed or cancelled.
How do I calculate delay without a dedicated delay field?
Subtract scheduled from actual (departure) or from estimated/actual (arrival). Keep delays in minutes for sorting and display.
What should I do if a user enters a codeshare flight number?
Normalize to the operating carrier’s record when possible. If codeshare mappings are available in your plan, resolve equivalents to a single operational flight and present both numbers in the UI.
Can I track multiple Aeromexico flights at once?
Yes. Use the airline flights or real-time endpoints for broader coverage, and the flight-info-by-flight-number call for per-flight details. Stagger requests and cache stable fields.
How do I handle missing gates or terminals?
Show “TBD” and refresh more frequently close to departure/arrival. Gate and terminal assignments can change; avoid long TTLs for these fields.
Build your Aeromexico flight status experience with focused, stable calls to the flight info by flight number endpoint and layer in schedules, airline-wide views, and historical analysis as your use cases grow. Start integrating today: Get your FlightLabs API key.