# New Route Launch Monitor (`apt_marble/new-route-launch-monitor`) Actor

Know the moment an airline adds, announces, starts or drops a route at the airports you watch. Schedule it and every run returns one row per change — with the destination, the airline and its own published first-flight date. Built for airport marketing, tourism boards and aviation press.

- **URL**: https://apify.com/apt\_marble/new-route-launch-monitor.md
- **Developed by:** [Hamza](https://apify.com/apt_marble) (community)
- **Categories:** Travel
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $5.00 / 1,000 route change detecteds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## New Route Launch Monitor

Know the moment an airline adds, announces, starts or drops a route at the airports you care about. Point it at a list of airports, put it on a schedule, and every run gives you one row per change — a new route, a route that just entered service, a route that has gone, or a route whose published details moved. Nothing else. No route lists to wade through, no diffing spreadsheets by hand, and no re-reading the same 200 destinations every week to spot the one that is different.

It is built for the people who have to notice first: airport marketing and route-development teams, tourism boards, aviation journalists, airline competitive-intelligence analysts and destination marketers.

### What you can do with it

- **Catch a competitor's launch on day one.** Watch a rival airport's networks and get an alert-shaped row the first time a new destination appears.
- **Track your own airport's route wins and losses** over time, with a dated record of when each one appeared and when it went.
- **Get ahead of the announcement.** Routes that are on sale but not yet flying come back marked `announced`, with the published first-flight date, so you can prepare coverage before the first flight. Only the airport-wide network publishes such a date; the two single-airline networks do not, and nothing is invented for them.
- **Know the day a route enters service**, not just the day it was announced — where a first-flight date is published, the run that spans it reports the route as `launched`.
- **See which airline is expanding at an airport**, one row per airline and destination, so a second carrier joining an existing route is its own event — dated by that carrier's own first flight, not by the route's history.
- **Feed a newsroom, a dashboard or a CRM.** Schedule it daily or weekly and every run appends only what changed since the last one.

### What you get

One row per change. A real, abridged result:

```json
{
  "changeType": "new",
  "detectedAt": "2026-08-16T19:02:34.800Z",
  "detectionMethod": "published-start-date",
  "carrier": "LS",
  "carrierName": "Jet2",
  "originIata": "LTN",
  "originCity": "London",
  "destinationIata": "AGP",
  "destinationCity": "Malaga",
  "destinationCountry": "Spain",
  "firstFlight": "2027-05-21",
  "routeFirstFlight": "2018-10-28",
  "launchStatus": "announced",
  "isDirect": true,
  "sourceFlaggedNew": true,
  "routeKey": "airport-network|ltn|agp|ls",
  "source": "airport-network",
  "collectedAt": "2026-08-16T19:02:34.800Z"
}
```

Two dates, because they are two different facts: London Luton–Malaga has been flown since 2018, and **Jet2** starts flying it on 21 May 2027. The row belongs to the airline, so it is dated by the airline.

### Input reference

| Field | Type | Default | What it does |
| --- | --- | --- | --- |
| `airports` | list of text | — (required) | The airports to watch, as three-letter codes, for example `DUB`, `BUD`, `LTN`. Up to 40 per run. |
| `sources` | list | all three | Which networks to compare at each airport: `ryanair`, `wizzair`, and `airport-network` for every airline serving that airport. |
| `changeTypes` | list | all four | Which changes become rows: `new`, `launched`, `dropped`, `updated`. |
| `watchlistName` | text | `default` | Keeps this watchlist's history apart from your others. Keep it the same between runs — it is how the actor knows what changed. |
| `lookbackRuns` | number | `1` | How many of your recent checks a run reports on. Raise it if you run daily but read the results weekly; repeated changes are marked. Maximum 30. |
| `language` | text | `en` | Language for city and country names: English, German, Spanish, French, Italian, Polish, Portuguese, Dutch or Hungarian. |
| `maxRows` | number | `5000` | Ceiling on how many rows a single run writes. Maximum 50,000. |
| `resetBaseline` | true/false | `false` | Forget this watchlist's history and treat today as the new starting point. Use it after you change the airports you watch. |

### Output fields

| Field | What it is |
| --- | --- |
| `changeType` | `new`, `launched`, `dropped` or `updated` |
| `detectedAt` | When this change was spotted |
| `previouslySeenAt` | When the route was last seen before this change |
| `firstSeenAt` | When this watchlist first saw the route |
| `detectionMethod` | How it was found — by comparison against your history, by a published start date, or by the airline's own new-route marker |
| `isBackfill` | True when the row repeats a change found in an earlier check |
| `carrier`, `carrierName` | The airline flying it |
| `carrierAlliance`, `carrierIsLowCost` | Airline profile, where published |
| `originIata`, `originName`, `originCity`, `originCountry` | The airport you are watching |
| `destinationIata`, `destinationName`, `destinationCity`, `destinationCountry`, `destinationCountryCode` | Where the route goes |
| `destinationLat`, `destinationLng` | Destination coordinates, for mapping |
| `firstFlight` | **This airline's** published first flight on this route, where one is published. Empty for an airline already flying it |
| `routeFirstFlight` | When any airline first flew the route, where that is published. Kept separate so an airline is never dated by another airline's history |
| `scheduleWindowStart` | Wizz Air only: the first departure of the schedule the airline currently has loaded. It is **not** a launch date — most of the network shares the same one — so nothing is derived from it and it never triggers a change |
| `launchStatus` | `announced` (not flying yet), `operating`, `withdrawn`, or `unknown` when no first-flight date is published |
| `isSeasonal`, `isDomestic`, `isDirect`, `isConnected` | Route flags, exactly as published |
| `flightsPerWeek` | Weekly frequency, where published |
| `sourceFlaggedNew` | True when the airline's own listing marks the route as recently added |
| `changedFields`, `previousValues` | On an `updated` row: what moved, and what it was before |
| `routeKey` | A stable identifier for this airline on this route |
| `source` | Which network the change came from |
| `language`, `collectedAt` | The language used and when the check ran |

Every run also writes a summary you can read alongside the results: how many airports were checked, how many changes of each kind were found, how many routes were recorded as a first-time baseline, and — kept deliberately separate — how many checks could not be completed.

### Pricing

You pay for two things, and only for work that actually happened.

| What | Price |
| --- | --- |
| Route change detected | **$5.00 per 1,000** results ($0.005 each) |
| Airport network checked | **$0.020** for each airport-and-airline network compared |

The second charge is the honest half of a monitor: comparing a 200-destination network and finding that nothing moved is a full day's work for this actor, and a quiet week is a good outcome, not a failed one. You are charged for the comparison whether or not it produces a row.

**Worked example.** You watch 10 airports across all three networks — 30 network comparisons per run, at $0.020 each, is $0.60. That run finds 12 changes, at $0.005 each, adds $0.06. The run costs **$0.66**. Running it every day for a month is about **$20**, and the first run of a new watchlist costs the same as any other.

You are never charged for a network comparison that could not be completed, and never for an airline that does not serve an airport you listed.

### Limits & what this actor cannot do

- **The first check of any airport is a baseline, not a launch report.** With nothing to compare against, the actor records what the networks look like and reports only the routes the airlines themselves mark as recently added or as not yet flying. Real change reporting starts with your second run. The same applies to any airport you add to an existing watchlist later.
- **A withdrawal is only published once two consecutive checks agree.** A route that vanishes from one check and returns on the next is never reported as dropped. This means a genuine cancellation reaches you one check later than it happened, which is the price of never sending a false one.
- **A check that could not be completed is reported as a failed check, never as "the airline dropped everything".** Those airports are left exactly as they were, and the run summary counts them separately from airports that were checked and found unchanged.
- **Route information is a snapshot at the moment of collection.** Airlines add, move and pull routes continuously, and a route seen now can change the same day.
- **This actor does not price, book or hold anything.** It reports network changes, not fares, seats or availability.
- **Only what the airline publishes is reported.** Only one of the three networks — the airport-wide one — publishes a first-flight date, so routes from the other two come back with `launchStatus: "unknown"` rather than a guessed date. Wizz Air publishes a schedule-window date that looks like a launch date and is not one: most of its network shares a single value, including routes flown since 2004, so it is reported under its own name and no launch status, launch report or change alert is ever built from it. A missing value is always left empty and never filled in — an unpublished weekly frequency stays empty and never becomes "0 flights per week".
- **The "recently added" markers are the airlines' own, and they are not all fresh.** Where a listing marks a route as new but **that airline's own** published first flight was years ago, the actor believes the date and leaves the route out of your results rather than headlining an old route as a launch. The route's own age is never used for this: an airline joining a route that others have flown for a decade is a launch, and is reported as one.
- **Seasonal designation is reported only where a network publishes one.** Where a network does not publish it, the field is empty rather than assumed.
- **City groupings are not airports.** Ask for a code that covers several airports in one city and the run tells you which airports it covers, so you can watch those instead. They are excluded as destinations too: a route to "Stockholm (All Airports)" is the same route as the one to Stockholm Arlanda, and reporting both would sell you one launch twice.
- **Very large watchlists have a memory ceiling.** A watchlist keeps history for up to 8,000 routes; beyond that, the least recently seen are dropped and the run says so. Split a very large watchlist in two to keep the full history.
- **Coverage is what each network publishes.** An airport not served by an airline is reported as exactly that, and is not billed.
- **Speed depends on the size of your watchlist and on how quickly the sources answer.** No fixed throughput is promised.
- **Each source's terms govern automated access.** You are responsible for using the results lawfully and in line with those terms.

### FAQ

**Do I need an account with any airline?**
No. Nothing is signed into and nothing is booked.

**Does it need my login or password?**
No. There is nothing to connect and nothing to authorise.

**Can I schedule it?**
Yes, and that is how it is meant to run. Daily or weekly is the sensible cadence; each run reports only what changed since the previous one.

**Why did my first run return so few rows when it says it checked hundreds of routes?**
Because a first run has nothing to compare against. It records the baseline and reports only the routes the airlines themselves flag as new or as not yet flying. From your second run on, every genuine change appears.

**Why is a route I know launched not in my results?**
Most likely the launch was announced before your watchlist started, so it was part of your baseline. It will still appear as `launched` on the run that spans its published start date, if the airline publishes one.

**Are these routes bookable?**
Routes marked `announced` are published as starting on a future date and may not be on sale yet. This actor reports what the airline publishes about its network; it does not check fares or seats and cannot confirm anything is available to buy.

**What happens if a check fails?**
The run reports it as a failed check and leaves that airport's history untouched, so nothing is falsely reported as dropped. If every check fails, the run itself ends as failed rather than quietly producing an empty result.

**Can I watch several separate lists of airports?**
Yes. Give each list its own watchlist name and their histories stay independent.

# Actor input Schema

## `airports` (type: `array`):

The airports whose route networks you want monitored, as three-letter airport codes — for example DUB, BUD, LTN. Each airport is checked against every network you select below. Up to 40 airports per run.

## `sources` (type: `array`):

Which route networks to compare at each airport. Ryanair and Wizz Air are watched directly, airline by airline. "Every airline at the airport" widens the same comparison to every carrier that serves it, so you also catch a legacy or long-haul launch.

## `changeTypes` (type: `array`):

Which changes you want as rows. "New" is a route that appeared since the last check. "Started flying" is a route already on the map whose published first flight date has now passed. "Dropped" is a route that has gone. "Details changed" covers a moved start date or a route becoming connecting rather than direct.

## `watchlistName` (type: `string`):

Keeps this watchlist's history separate from your others. Use one name per set of airports and keep it the same between runs — that is how the actor knows what changed. Letters, digits and hyphens.

## `lookbackRuns` (type: `integer`):

How many of your recent checks a run should report on. 1 gives you only what changed since the last check. Raise it if you run daily but read the results weekly, and each run will repeat the changes found in the previous checks as well, marked as repeats.

## `language` (type: `string`):

The language used for city and country names on your results. Airport codes, dates and flags are the same in every language.

## `maxRows` (type: `integer`):

A ceiling on how many change rows a single run writes, so a very large watchlist cannot produce an unexpectedly big result set.

## `resetBaseline` (type: `boolean`):

Forget this watchlist's history and record today's networks as the new starting point. Use it after changing the airports you watch. This run will report only the launches the airlines themselves flag, not every route as new.

## Actor input object example

```json
{
  "airports": [
    "DUB",
    "BUD",
    "LTN"
  ],
  "sources": [
    "ryanair",
    "wizzair",
    "airport-network"
  ],
  "changeTypes": [
    "new",
    "launched",
    "dropped",
    "updated"
  ],
  "watchlistName": "default",
  "lookbackRuns": 1,
  "language": "en",
  "maxRows": 5000,
  "resetBaseline": false
}
```

# Actor output Schema

## `changes` (type: `string`):

One row per route change: new, started flying, dropped or details changed.

## `changesCsv` (type: `string`):

The same change rows as a spreadsheet.

## `runSummary` (type: `string`):

What was checked, what changed, and which checks could not be completed.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "airports": [
        "DUB",
        "BUD",
        "LTN"
    ],
    "sources": [
        "ryanair",
        "wizzair",
        "airport-network"
    ],
    "changeTypes": [
        "new",
        "launched",
        "dropped",
        "updated"
    ],
    "watchlistName": "default",
    "lookbackRuns": 1,
    "language": "en",
    "maxRows": 5000
};

// Run the Actor and wait for it to finish
const run = await client.actor("apt_marble/new-route-launch-monitor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "airports": [
        "DUB",
        "BUD",
        "LTN",
    ],
    "sources": [
        "ryanair",
        "wizzair",
        "airport-network",
    ],
    "changeTypes": [
        "new",
        "launched",
        "dropped",
        "updated",
    ],
    "watchlistName": "default",
    "lookbackRuns": 1,
    "language": "en",
    "maxRows": 5000,
}

# Run the Actor and wait for it to finish
run = client.actor("apt_marble/new-route-launch-monitor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "airports": [
    "DUB",
    "BUD",
    "LTN"
  ],
  "sources": [
    "ryanair",
    "wizzair",
    "airport-network"
  ],
  "changeTypes": [
    "new",
    "launched",
    "dropped",
    "updated"
  ],
  "watchlistName": "default",
  "lookbackRuns": 1,
  "language": "en",
  "maxRows": 5000
}' |
apify call apt_marble/new-route-launch-monitor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,apt_marble/new-route-launch-monitor"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/WhgNJIcIjxWGe6gRe/builds/HaYNwHF5jCx9NfHBc/openapi.json