CDG Flight Schedule API: Charles de Gaulle as JSON

You need a reliable, JSON-based feed of real-time departures from Paris Charles de Gaulle (CDG) to power a travel app, an airport display, or an operations dashboard. By the end of this guide, you’ll be able to fetch the CDG departures board from FlightLabs, filter it to just the airlines you need (for example, Air France), parse status and timing fields, and ship an integration that stays fresh with sensible polling and caching.

The CDG departures board as an API

FlightLabs exposes the CDG departures board via a single REST endpoint that returns JSON. You call it with the airport’s IATA code (CDG) and a type that specifies departures. The result is a structured list of flights you can render or enrich downstream.

You can get an API key with a 7-day trial. The Starter plan is $24.99/mo and includes 4,000 calls, which is sufficient for many prototypes and moderate-traffic boards. To begin, create your account and obtain an access key:

• Register
• Keep the access_key handy; you’ll pass it in the request.

For general product info and examples, see the FlightLabs homepage: www.goflightlabs.com. You can also browse the Documentation and work through the MCP to understand parameters and fields.

Endpoint and parameters you will use

To request the Charles de Gaulle departures board, use:

GET https://api.goflightlabs.com/flights-schedules

Key parameters:

• iataCode=CDG — the airport you’re querying (Paris Charles de Gaulle).
• type=departure — specifies that you want departures.
• airline_iata=AF — optional filter to return only Air France flights.

CDG curl request and the official JSON shape

Below is the official request. Replace YOUR_API_KEY with your access key to run it. This call asks for the CDG departures board.

curl "https://api.goflightlabs.com/flights-schedules?access_key=YOUR_ACCESS_KEY&iataCode=CDG&type=departure"

And here is the official sample response shape the API returns. It shows a board where dep_iata is set to JFK for the sample day, but the structure and keys are the same for CDG. When you call the endpoint with iataCode=CDG, a live response sets dep_iata to CDG.

{
  "success": true,
  "type": "departure",
  "data": [
    {
      "airline_iata": "TG",
      "flight_iata": "TG6173",
      "dep_iata": "JFK",
      "dep_terminal": "7",
      "dep_gate": "5",
      "dep_time_utc": "2026-09-16 17:30",
      "arr_iata": "HND",
      "status": "active"
    }
  ]
}

What to look for in the response:

• Status: Use the status field to tell whether a flight is scheduled, active, delayed, cancelled, or similar. Your UI logic typically keys off this first.
• Times: Scheduled and estimated times help you show planned vs. current timing. Base your countdowns on estimated when present; fall back to scheduled otherwise.
• Delays: A delay field indicates how late (often in minutes). Check for null/missing when a delay is not set.
• Terminals and gates: Terminal and gate fields are critical for signage. These may be absent for some flights or change frequently, so refresh regularly.
• Codeshares: A codeshared object or code fields identify operating vs. marketing carriers; surface these carefully to avoid duplicates on your board.
• Airline and flight identifiers: airline_iata, flight_iata, and related fields are useful for sorting, filtering, or deep-linking into carrier workflows.
• dep_iata and arr_iata: Departure and arrival airport IATA codes. For CDG departures, expect dep_iata=CDG.

If any fields are missing for a given flight, treat them as unknown and avoid displaying stale or placeholder values. The response may also include metadata about pagination when you fetch larger boards; see the Documentation for paging controls and limits.

A minimal Python example for CDG departures (with optional Air France filter)

This example calls the same endpoint as the curl above and prints a compact row for each flight. It demonstrates filtering by airline_iata=AF to get only Air France flights.

import os
import requests
from datetime import datetime

API_URL = "https://api.goflightlabs.com/flights-schedules"
API_KEY = os.environ.get("FLIGHTLABS_KEY", "YOUR_API_KEY")

params = {
    "access_key": API_KEY,
    "iataCode": "CDG",
    "type": "departure",
    # Uncomment to filter to Air France only:
    # "airline_iata": "AF",
}

r = requests.get(API_URL, params=params, timeout=20)
r.raise_for_status()
data = r.json()

# Some integrations return a top-level success indicator; handle it defensively.
# If a success flag and an error object appear, log/raise appropriately.
if isinstance(data, dict) and data.get("success") is False:
    err = data.get("error", {})
    raise SystemExit(f"FlightLabs API error: {err}")

flights = data if isinstance(data, list) else data.get("data", [])

def safe(dt):
    # Best-effort to parse timestamps; fields may be ISO strings or null.
    if not dt:
        return "-"
    try:
        # When the string includes a timezone offset, fromisoformat will retain it.
        return datetime.fromisoformat(dt).isoformat()
    except Exception:
        return str(dt)

for f in flights:
    # Field names mirror the official sample; guard everything.
    status = f.get("flight_status") or f.get("status") or "-"
    airline = (f.get("airline") or {}).get("iata") or f.get("airline_iata") or "-"
    flight_iata = (f.get("flight") or {}).get("iata") or f.get("flight_iata") or "-"
    dep = f.get("departure") or {}
    arr = f.get("arrival") or {}
    dep_airport = dep.get("iata") or f.get("dep_iata") or "-"
    arr_airport = arr.get("iata") or f.get("arr_iata") or "-"
    dep_sched = safe(dep.get("scheduled"))
    dep_est = safe(dep.get("estimated"))
    gate = dep.get("gate") or "-"
    terminal = dep.get("terminal") or "-"
    delay = dep.get("delay")
    delay_str = f"{delay} min" if delay is not None else "-"

    print(f"{status:10} {airline:2} {flight_iata:8} {dep_airport:3} → {arr_airport:3}  "
          f"Sched {dep_sched}  Est {dep_est}  T{terminal} G{gate}  Delay {delay_str}")

Notes for production:

• Null-safety: Many subfields can be absent. Always guard nested keys.
• Timestamps: Fields are delivered as date/time strings; preserve offsets if present, and convert to local time zones in your UI if needed.
• Status-first rendering: If flight_status or status signals cancelled/diverted, highlight that and suppress stale gate/estimate values.

Going live with CDG

Steps

1. Register — 7-day trial.
2. Copy your access_key.
3. GET schedules with iataCode=CDG and type=departure.
4. Cache responses for 1–5 minutes to balance freshness and cost.

You can also explore schema and examples in the MCP and the Documentation. To pull CDG departures right away, start here: Register.

Product overview and SDKs are available at www.goflightlabs.com.

Filtering, pagination, and performance

Filtering by airline: If your use case is specific to Air France, add airline_iata=AF to the query. This reduces payload size and simplifies UI rendering.

Pagination: Large boards can span many flights within a period. When the API returns paginated results, iterate using the pagination controls documented in the product Documentation until all result pages are consumed. Always cap page sizes appropriate to your UI to reduce over-fetching.

Polling and caching: Live departures are dynamic. For most displays:

• Poll every 1–5 minutes and cache responses for the same interval.
• Avoid re-rendering the entire board on each poll. Instead, patch updates flight-by-flight by ID or flight_iata key.
• Back off on errors (e.g., exponential backoff to avoid hot loops on temporary issues).

Working with time zones, delays, and statuses

Time zones: Flight time fields are date/time strings. Treat them as canonical timestamps; when an explicit timezone offset is present, preserve it in downstream logic. If your UI is location-based (e.g., a CDG terminal screen), convert times to the local CDG time zone for consistency. For analytics, you may prefer UTC comparisons; normalize before aggregating.

Delays: When a delay field is present, it’s typically a magnitude you can display as minutes late. If it’s missing or null, treat as “no reported delay.” Always show estimated time when available; it’s usually the best indicator for passenger-facing signage.

Status changes: Expect the status to evolve from scheduled to active to landed or cancelled. For diverted or cancelled flights, remove gate and estimate anxiety by graying out or hiding those fields, and surface a clear label derived from the status field.

Codeshares: If the response contains codeshare details, decide whether to deduplicate visually (e.g., show the operating flight once and list codeshares inline) or list all marketing numbers. Consistency here reduces confusion for travelers.

Error handling and missing data

At times an API response can indicate an error (for example, a top-level success=false with error context) or contain partial data. Best practices:

• Check HTTP status and parse the JSON body even on errors for structured error info.
• Guard all nested fields: terminal, gate, delay, estimated can be absent until confirmed.
• Log and surface diagnostics out-of-band; never show raw errors to end users.
• Fallback logic: if estimated is missing, use scheduled; if gate is missing, omit it from the UI rather than showing a placeholder.

Testing, observability, and rollout

Before rolling out, test with a subset of parameters (e.g., airline_iata=AF) and confirm your parser against the official sample shape. In staging, crank the polling cadence down to avoid exhausting your plan. Add monitoring to track:

• Update lag: compare scheduled vs. estimated shifts to confirm freshness.
• Refresh success rates: alert on consecutive fetch failures and back off appropriately.
• Throughput: keep an eye on monthly call counts relative to plan limits.

Deployment checklist for a CDG departures board

• Authentication: Store the access key securely and rotate when needed.
• Endpoint: Use GET https://api.goflightlabs.com/flights-schedules with iataCode=CDG and type=departure.
• Optional filters: airline_iata=AF for Air France-only workflows.
• Parsing: Handle status, scheduled/estimated times, delay, terminal, gate, dep_iata/arr_iata, and codeshares.
• Resilience: Cache results 1–5 minutes; retry with backoff on transient failures.
• UX: Prefer estimated over scheduled when present; make status the primary label.
• Docs and tools: Validate against the Documentation and explore via MCP.

FAQ

How do I limit the board to Air France departures from CDG?
Add airline_iata=AF alongside iataCode=CDG and type=departure.

Why does the official sample show dep_iata=JFK?
The sample demonstrates the response structure using JFK on a specific day. When you call the endpoint with iataCode=CDG, live results are for CDG and will set dep_iata to CDG in the response.

How often should I poll for live departures?
Cache for 1–5 minutes and poll on the same cadence. This keeps your board fresh without unnecessary load.

What if terminal or gate is missing?
Treat missing fields as unknown and hide them in the UI. These fields can be empty until the airport publishes them or when a flight is cancelled/diverted.

How do I handle large result sets?
Use the pagination controls described in the Documentation and iterate until all pages are fetched. Keep page sizes practical for your UI.

Build your CDG departures integration now. Start your 7-day trial and get your access key with a quick Register. For an overview of the platform and additional capabilities, visit www.goflightlabs.com.