Charles de Gaulle Airport (CDG) Flight API

You need reliable, developer-friendly flight data for Charles de Gaulle in order to power arrival boards, trigger delay alerts, or keep schedules in sync. By the end of this guide, you’ll query CDG schedules via FlightLabs, parse status/terminal/gate fields for live displays, and plan how to poll and cache responses in production.

CDG context and what you can build

Paris Charles de Gaulle Airport serves the Paris region in France with IATA code CDG and ICAO code LFPG. Developers track CDG because it is a major European hub with multi-terminal operations, complex connections, and frequent long-haul activity that benefits from accurate schedules and real-time status.

FlightLabs exposes CDG data over a simple, API key–authenticated REST interface returning JSON. You can integrate it into travel apps, airport displays, logistics and corporate travel tools, or analytics dashboards. Explore the platform at www.goflightlabs.com and use the links below to register and access the documentation.

Endpoints you’ll use for CDG

• Flight Schedules (for CDG arrivals or departures): https://www.goflightlabs.com/flights-schedules
• Real-time Flight Tracking (for live status/position): https://www.goflightlabs.com/real-time
• Flight History (for retrospectives and audits): https://www.goflightlabs.com/flights-history
• Future Flights (for planning beyond standard schedule windows): https://www.goflightlabs.com/future-flights
• Flight Delay Predictions (for proactive alerting): https://www.goflightlabs.com/flight-delay
• Routes (to map coverage and connectivity): https://www.goflightlabs.com/retrieve-routes

All requests are served from the API host at https://api.goflightlabs.com/ and require your API key. If you’re not set up yet, visit Register to get an API key. A 7-day or 50-request trial and a Starter plan at $24.99/mo are available.

Query CDG schedules: curl example

For schedules tied to CDG, use the schedules endpoint and provide the airport IATA and whether you want arrivals or departures. The path structure is:

/flights-schedules?iataCode=CDG&type=arrival

Example request:

curl -G "https://api.goflightlabs.com/flights-schedules" \
--data-urlencode "iataCode=CDG" \
--data-urlencode "type=arrival" \
--data-urlencode "api_key=YOUR_API_KEY"

This request returns schedule entries for flights arriving at CDG. Switch type to departure to fetch departures. Use your own API key value in place of YOUR_API_KEY.

What a schedule response looks like

Below is an official example schedule response structure. Your CDG query will follow this JSON shape, with CDG appearing in the arrival or departure section depending on your query.

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

Key fields you’ll use:

• flight_number: Airline flight number identifier used for display and linking with other endpoints.
• departure.scheduled and arrival.scheduled: ISO 8601 timestamps in UTC for schedule boards and delay calculations.
• departure.terminal and arrival.terminal: Terminal details critical for airport signage and traveler guidance.
• aircraft.type and aircraft.registration: Optional display metadata or for ops/maintenance context.
• airline.iata and airline.name: For branding and airline filtering.

Real-time status fields you’ll care about

To power live boards and alerts, pair schedules with real-time flight tracking. Below is the official real-time sample structure you can expect when tracking a flight. While your CDG-targeted calls will filter for flights arriving to or departing from CDG, the structure remains the same.

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

Important fields:

• status: Use this to label phases like scheduled, en-route, landed; also handle exceptional states like cancelled or diverted where applicable.
• departure.scheduled, departure.actual: The difference drives departure delay minutes; render both for transparency.
• arrival.scheduled, arrival.estimated: Use estimated to update ETAs and gate clocks.
• terminal and gate: Display-critical details for both ends of the flight; at CDG, terminals can determine connection workflows.
• position: Use latitude/longitude/altitude/speed/heading for maps, proximity alerts, or taxi-in notifications.

JavaScript example: fetch and normalize CDG arrivals

The following sample queries the schedules endpoint for CDG arrivals and prints a minimal board-friendly structure. It also demonstrates parsing terminals and UTC-to-local considerations. Adjust for your framework or caching layer as needed.

async function fetchCdgArrivals() {
const params = new URLSearchParams({
iataCode: "CDG",
type: "arrival",
api_key: "YOUR_API_KEY"
});

const res = await fetch(`https://api.goflightlabs.com/flights-schedules?${params.toString()}`);
if (!res.ok) {
throw new Error(`API error: ${res.status}`);
}
const payload = await res.json();

if (!payload.success || !payload.data || !Array.isArray(payload.data.schedules)) {
throw new Error("Unexpected response shape");
}

// Convert a UTC timestamp to a local Paris time string (simplified; prefer a timezone library in production)
const toParisLocal = (utcIso) => {
const d = new Date(utcIso);
// Timezone handling depends on your runtime; use Intl for display only
return new Intl.DateTimeFormat("fr-FR", {
timeZone: "Europe/Paris",
hour: "2-digit",
minute: "2-digit",
hour12: false
}).format(d);
};

const arrivals = payload.data.schedules.map((item) => {
const flightNumber = item.flight_number;
const airlineIata = item.airline?.iata;
const depAirport = item.departure?.airport;
const arrAirport = item.arrival?.airport;
const arrTerminal = item.arrival?.terminal || "";
const schedUtc = item.arrival?.scheduled;

return {
flight: `${airlineIata || ""}${flightNumber || ""}`,
origin: depAirport || "",
destination: arrAirport || "",
terminal: arrTerminal,
arrival_time_local: schedUtc ? toParisLocal(schedUtc) : ""
};
});

return arrivals;
}

fetchCdgArrivals()
.then((rows) => console.table(rows))
.catch((err) => console.error(err));

Notes:

• Timestamps are in UTC. Use the Europe/Paris timezone for CDG user-facing times.
• Some fields may be missing depending on airline or data source; use optional chaining and defaults.
• For live ETAs, pair this with a real-time request keyed by flight number or IATA/ICAO identifiers.

How to design polling, caching, and error handling

• Polling frequency: For near-real-time boards, 30–60 seconds for real-time status is typical. For schedules (which change less often), 5–10 minutes may suffice. Throttle and backoff when responses are unchanged to reduce API usage.
• Caching: Cache schedule lists keyed by iataCode and type (arrival/departure). Invalidate on hour boundaries or when a tracked flight’s status changes.
• Time zones: All timestamps in samples are UTC (e.g., 2024-03-20T14:15:00Z). Convert to local Paris time only at the display layer to keep storage/logic consistent.
• Cancelled/diverted: Use status from the real-time endpoint to surface cancellations or diversions prominently. When status indicates cancelled, hide gate/terminal or mark them as N/A. For diverted, update the arrival airport code and notify subscribers.
• Pagination: Schedule datasets can be large. If the response indicates pagination (via documented cursors or page markers in the API), iterate until complete for batch jobs. Keep UI requests scoped to a rolling window (e.g., next 6 hours) to minimize pages. See the Documentation for the current pagination pattern.
• Retries and timeouts: Implement timeouts per request and exponential backoff on transient network errors. Log the full URL (minus api_key) and status codes for diagnostics.

Three practical CDG use cases and the fields that power them

1) Airside arrival boards

• Data: schedules for iataCode=CDG&type=arrival
• Fields: arrival.scheduled (board time), arrival.terminal (display column), airline.iata + flight_number (flight ID), aircraft.type (optional iconography)
• Enhancement: For flights entering final approach, merge in real-time arrival.estimated and status to reflect delays.

2) Delay alerts for pickup coordination

• Data: real-time tracking by flight identifier, refreshed every 30–60 seconds during the inbound phase
• Fields: status (notify on transitions like en-route → landed), arrival.estimated (ETA updates), gate/terminal for pickup routing inside CDG
• Trigger logic: Send alerts when ETA drifts more than N minutes from scheduled, and again at touchdown or gate arrival if available.

3) Schedule sync for corporate travel calendars

• Data: schedules endpoint batched daily for CDG inbound/outbound
• Fields: departure.scheduled, arrival.scheduled (populates calendar blocks), airline.iata + flight_number (event title), terminals (notes field)
• Enhancement: Post-booking, a periodic check against real-time status to reconcile cancellations or significant delays.

Technical comparison of FlightLabs endpoints for CDG-centric builds

When anchoring features to CDG, pick the endpoint that matches your workflow. The table below compares commonly used endpoints specifically in the context of CDG operations.

Design notes specific to CDG

• Terminals: CDG has multiple terminals and concourses. Rely on arrival.terminal and departure.terminal for signage and wayfinding. Gate is an additional, late-binding detail from the real-time endpoint.
• Time conversion: Store UTC in your database. Convert to Europe/Paris only for display. Daylight saving shifts won’t affect stored values in UTC.
• Merging schedule + real-time: Keep a keyed index by airline IATA + flight_number (and date) to join schedule rows with live status updates. Fall back gracefully when either side is missing a field.
• Service windows: Not all airlines update gate data far in advance. Expect empty gate values until aircraft assignment is firm.
• Backfills: For analytics, complement real-time feeds with Flights History to reconstruct what happened on a given operating day at CDG.

Production tips: performance, quotas, and tooling

• Response sizes: Limit schedule queries to the smallest useful window (e.g., arrivals in the next 6–12 hours) to keep payloads small. If the API supports window parameters, prefer them. Otherwise, filter client-side and cache aggressively.
• Rate management: Consolidate UI refresh cycles to avoid duplicate calls from multiple components. Consider a server-side cache layer and broadcast updates to clients via WebSockets or SSE.
• Resilience: If a real-time call fails, degrade gracefully to schedule-only data and mark status as unknown rather than stale.
• Testing: Use the MCP to explore models and responses interactively during development.
• Docs-first integration: Keep the Documentation open to confirm available filters, pagination strategy, and authentication options. The base platform is also accessible at www.goflightlabs.com.

End-to-end workflow example for CDG arrivals

Step 1: Fetch the schedule list

Call /flights-schedules with iataCode=CDG&type=arrival. Cache for 5–10 minutes. Persist UTC timestamps and terminals.

Step 2: Resolve live status for flights approaching CDG

For flights scheduled to arrive in the next 180 minutes, query the real-time endpoint by their IATA/ICAO identifiers. Merge status, estimated time, and gate into your schedule row.

Step 3: Update presentation and alerts

• Boards: If status is en-route and estimated > scheduled, show delay minutes in red and update clock to estimated.
• Notifications: Fire a message when status changes (e.g., landed), or when ETA shifts more than a threshold.
• Cleanup: After arrival + buffer (e.g., 60 minutes), evict flights from the live set to save polling budget.

Security and operations

• API key handling: Store the key server-side and proxy requests from clients. Avoid embedding keys in client apps.
• Observability: Add structured logs with flight identifiers, CDG tag, and request correlation IDs. Monitor non-200 rates.
• Versioning: Track response schema changes. Use contract tests to catch field removals or renames.

FAQ

How do I filter schedules to only departures from CDG?
Use type=departure with iataCode=CDG on the schedules endpoint. Filter client-side by time window to keep the board focused.

How should I handle time zones for CDG?
Store and compute in UTC. Convert to Europe/Paris only for display. Use standardized libraries to format local times correctly during daylight saving changes.

What indicates a cancelled or diverted flight?
Check status from the real-time endpoint. When cancelled, suppress gate/terminal display and mark as cancelled. If diverted, update the arrival airport field and notify downstream systems.

Is there pagination for schedule results?
If the schedules response is paginated, iterate using the documented parameters or cursors until you’ve collected the desired window. Consult the Documentation for current pagination behavior.

Can I see live positions approaching CDG?
Yes. Use the real-time endpoint to retrieve position.latitude, position.longitude, altitude, speed, and heading. Combine with ETA to power maps and proximity alerts.

Ready to build your CDG integration with schedules, real-time status, and analytics? Get your API key now via Register, then explore parameters and code snippets in the Documentation.