AMS Flight Schedule API: Schiphol Departures as JSON

You need a reliable way to pull Amsterdam Schiphol (AMS) departures into your app as structured JSON. By the end of this guide you’ll know exactly how to request the AMS departure board from FlightLabs, interpret the schedule payload, filter it properly for AMS, and handle the practical details around time zones, polling, errors, and caching.

What the AMS departures API returns

FlightLabs exposes Amsterdam Schiphol departures via a single REST endpoint that returns a departures board as JSON. Each record in the response corresponds to one scheduled or live departure and includes airport identifiers (IATA), timing data (scheduled/estimated/actual where available), operational status, and other operational fields such as terminals, gates, delays, and codeshare details when present.

You request AMS departures with GET https://api.goflightlabs.com/flights-schedules, passing two query parameters:

• iataCode=AMS
• type=departure

The response is a JSON object containing an array of schedule items. Within each item, the airport fields follow the same shape the API uses globally. The key to filter on for the departure airport is dep_iata. For a live AMS call, dep_iata is set to AMS.

Developers commonly use this endpoint to power airport departure boards, traveler notifications, gate dashboards, or ETD views in logistics systems—anywhere you need the “who, when, and where” of upcoming flights leaving Schiphol.

For general API information, visit goflightlabs.com and the Documentation. If you’re using tools that integrate model or function-calling workflows, review the MCP hub.

Get access in minutes

FlightLabs offers a 7-day trial on the Starter plan ($24.99/mo for 4,000 calls). The quickest way to try AMS departures is to register, copy your access key, and make your first request:

1. Sign up for an API key: Register.
2. Copy your access_key from the dashboard.
3. Call the schedules endpoint with iataCode=AMS and type=departure.
4. Filter the returned data[] by dep_iata to ensure only AMS departures are shown.

You can also explore the platform and pricing at goflightlabs.com.

Request: AMS departures

Use the following curl to fetch the Schiphol departures board. Replace YOUR_API_KEY with your FlightLabs access key.

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

In all production apps, secure your key and route calls through a backend you control.

Optional: a minimal curl you can paste right now

curl -s "https://api.goflightlabs.com/flights-schedules?access_key=YOUR_API_KEY&iataCode=AMS&type=departure"

This is functionally the same request and is useful for a quick smoke test from your terminal.

Response format and the fields that matter

The following is the official sample shape from the schedules endpoint. It demonstrates the JSON structure and field names you should expect to work with. Note: this sample row shows a different airport in the dep_iata field (JFK) because it’s an official example—when you query AMS, dep_iata will be AMS. Filter by dep_iata === "AMS" in your code to keep your list precise.

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

Key fields you’ll use in an AMS departures app (names as shown in the sample):

• dep_iata: IATA code of the departure airport. For Schiphol, this will be AMS on live queries.
• arr_iata: IATA code of the arrival airport for the flight.
• status: The operational state of the flight (for example, scheduled, active, landed, cancelled, diverted). Treat this as authoritative for whether to show, update, or hide a flight in your board.
• Timing fields: You’ll typically see scheduled, estimated, and sometimes actual timestamps for departure and arrival. Use scheduled for the baseline display, estimated for countdowns, and actual when available for completed events.
• Operational details: Many responses include terminal and gate for both departure and arrival airports, and delay values (commonly in minutes). Display these to travelers and ops teams; they can change frequently, so update your cache often.
• Codeshare information: If a flight is operated by one carrier but marketed by another, the response can include codeshare identifiers. If you aggregate by flight number, consider grouping codeshares together in your UI.

If a field is missing for a record, it means the data was not available at the time of the request. Your parsing logic should handle missing values gracefully and omit the UI element instead of rendering “null” or “undefined”.

Production-ready Python example

The snippet below calls the same AMS departures endpoint, filters by dep_iata, and prints a compact row for each flight. It also shows how to handle success flags and missing fields without breaking your UI.

import os
import requests
from datetime import datetime, timezone

ACCESS_KEY = os.getenv("FLIGHTLABS_KEY", "YOUR_API_KEY")
URL = "https://api.goflightlabs.com/flights-schedules"

params = {
    "access_key": ACCESS_KEY,
    "iataCode": "AMS",
    "type": "departure",
}

resp = requests.get(URL, params=params, timeout=20)
resp.raise_for_status()  # network/HTTP errors

payload = resp.json()

# Handle the FlightLabs "success" wrapper pattern if present
if isinstance(payload, dict) and payload.get("success") is False:
    # The API may include 'error' with details
    err = payload.get("error") or {}
    raise SystemExit(f"API error: {err.get('code')} {err.get('type')} {err.get('info')}")

data = payload.get("data") if isinstance(payload, dict) else None
if not isinstance(data, list):
    raise SystemExit("Unexpected response format: no data[] array found")

def to_str(ts):
    # Many responses include ISO-8601 or epoch-like values; keep UTC internally.
    if not ts:
        return ""
    try:
        # If already ISO-8601 string, return as-is for now.
        if isinstance(ts, str):
            return ts
        # If epoch seconds, convert to ISO-8601 UTC as a fallback.
        if isinstance(ts, (int, float)):
            return datetime.fromtimestamp(ts, tz=timezone.utc).isoformat()
    except Exception:
        pass
    return str(ts)

rows = [row for row in data if row.get("dep_iata") == "AMS"]

for row in rows:
    dep = row.get("dep_iata") or ""
    arr = row.get("arr_iata") or ""
    status = row.get("status") or ""
    # If the sample includes nested departure/arrival blocks, prefer their scheduled/estimated/actual fields.
    dep_sched = to_str(row.get("departure", {}).get("scheduled") if isinstance(row.get("departure"), dict) else row.get("dep_time"))
    dep_est = to_str(row.get("departure", {}).get("estimated") if isinstance(row.get("departure"), dict) else None)
    term = (row.get("departure", {}) or {}).get("terminal") if isinstance(row.get("departure"), dict) else row.get("dep_terminal")
    gate = (row.get("departure", {}) or {}).get("gate") if isinstance(row.get("departure"), dict) else row.get("dep_gate")
    delay = (row.get("departure", {}) or {}).get("delay") if isinstance(row.get("departure"), dict) else row.get("delay")

    print(f"{dep}->{arr} | status={status} | sched={dep_sched} est={dep_est} | T{term or ''} G{gate or ''} | delay={delay or 0}")

Notes on the parsing:

• The example tolerates either flat or nested timing fields. Use the exact field names you see in your responses; FlightLabs schedules are consistent across airports, but fields can be absent when data isn’t available.
• Canonicalize times to UTC internally, then present in Europe/Amsterdam for end users. Most UIs benefit from showing “local time” plus a subtle “updated at” indicator.
• Always filter by dep_iata == "AMS" so you don’t display connecting legs or non-AMS rows if your query shape changes later.

Polling, caching, and error handling

Departures data changes frequently near pushback. A practical approach is to poll more often for near-term flights and less often for later flights:

• Within 2–3 hours of scheduled departure: poll every 30–90 seconds and cache for 30–60 seconds.
• Beyond 3 hours out: poll every 3–10 minutes and cache for 2–5 minutes.

Use HTTP caching headers where provided and implement an in-memory or shared cache (Redis) in your backend to protect your API quota. If you operate multiple boards (e.g., different terminals or airline filters), consolidate them behind a single fetch to the schedules endpoint and fan out internally.

On errors, check for an explicit success: false in the JSON and examine any error object fields for more context. For network or 5xx issues, apply exponential backoff. Log complete request IDs and parameters (excluding secrets) to reproduce incidents quickly.

Time zones and consistent timestamps

Flight schedules can include timestamps in different representations. Keep these principles in mind:

• Normalize everything to UTC in your backend logic.
• Display local time for Schiphol as Europe/Amsterdam in your UI. If you show both scheduled and estimated times, label them clearly.
• If only scheduled times are available, avoid displaying countdowns; switch to countdowns when estimated or actual times appear.

Be careful around daylight saving time changes in Europe/Amsterdam. Storing UTC internally prevents most pitfalls; convert to the local time zone at the final display layer.

Handling cancelled, diverted, and codeshare flights

Use the status field to control presentation:

• cancelled: hide from traveler alerts, or show with a strike-through and a prominent “Cancelled” badge.
• diverted: keep visible with a “Diverted” state; do not treat as departed from AMS if the payload indicates it left a different airport.
• scheduled/active: display normally, highlighting changes in gate, terminal, or ETD as new data arrives.

If the payload includes codeshare information, group codeshare flight numbers under the operating leg to avoid duplicating a physical flight in your list. For airline-specific boards, filter on the marketing or operating identifiers depending on your use case.

Pagination and result sizes

Schedules can be lengthy during peak periods. When the response indicates pagination (for example, by including a paging object or documenting page/limit parameters), follow the documented pattern in the Documentation to iterate through all results. If your UI only needs near-term flights, cap the time window on your backend and cache the combined result set for reuse by multiple clients.

Field-by-field checklist for AMS departures

As you wire up AMS departures in production, verify you’re handling these fields and states correctly:

• dep_iata is AMS (filter strictly to avoid accidental inclusion of other airports).
• arr_iata is present and used for route display.
• status-driven UI (scheduled, active, landed, cancelled, diverted).
• scheduled, estimated, and actual times handled when available; missing values do not break rendering.
• terminal and gate changes cause a visible update in your UI.
• delay (if present) adjusted in minutes and reflected in messaging.
• codeshare grouping to reduce clutter.
• Errors and rate limiting handled with retries and caching to stay within plan limits.

Going live at Schiphol

End-to-end steps

1. Create an account: Register (7-day trial on the Starter plan with 4,000 calls).
2. Store your access_key in a secure secret manager; never ship it in client-side code.
3. Pull AMS departures from /flights-schedules with iataCode=AMS and type=departure.
4. Filter data by dep_iata and present only Schiphol departures.
5. Implement polling, caching, and status-aware rendering for a smooth traveler or ops experience.

Troubleshooting tips

• I get rows for an unexpected airport: Confirm you’re filtering by dep_iata == "AMS". The official sample may show other airports; that’s expected for examples.
• Fields are occasionally missing: Schedules update in real time. Code defensively with null checks and fallback labels.
• Time math looks wrong: Normalize to UTC internally, convert to Europe/Amsterdam for display, and double-check DST boundaries.
• High traffic pages: Use a server-side cache, refresh incrementally, and fan out to clients via SSE/WebSockets.

FAQ

How do I get only AMS departures?
Call GET https://api.goflightlabs.com/flights-schedules with iataCode=AMS and type=departure, then filter the returned data[] to rows where dep_iata equals AMS.

Why does the sample show dep_iata: JFK?
It’s an official example demonstrating the response shape. In live AMS calls, dep_iata is AMS. Always filter by dep_iata to guarantee you’re showing Schiphol departures.

How often should I poll for real-time updates?
Poll more frequently for flights departing within the next few hours (e.g., every 30–90 seconds) and less frequently for later flights (e.g., every 3–10 minutes). Cache between polls to reduce API usage.

What if the API returns success=false?
Inspect the error object in the response (if present) for details, log the event, and back off before retrying. Typical causes include invalid keys or temporary upstream issues.

How do I handle pagination?
If the response or docs indicate pagination, follow the documented pattern to retrieve all pages. If your UI only needs a short time window, limit your scope and cache.

Ready to ship AMS departures as JSON? Start your 7-day trial, grab your API key, and integrate the schedules endpoint today: Register. Explore platform details and tools in the MCP and the full Documentation.