Telling Demo Flights from Real Ones

Telling Demo Flights from Real Ones

Someone walks past the board and says the flights look wrong, or made up, or the same as yesterday. This article shows you how to prove whether the screen is really on demo data, lists the five situations that produce it, and — just as important — walks through the symptoms that look like demo data but come from something else. Most reports we see turn out to be the second kind.

Start with the test, because it takes a minute and it settles the question. Everything after it assumes you already know the answer.

The only reliable test

The board fetches its flights from /api/flights/<hotelId>, and that response says outright which kind of data it carries. Open the display URL on any computer, press F12, go to the Network tab, filter for flights, reload the page, and click the request. In the response body, look at the top-level fields:

Two things about this request will mislead you if nobody warns you. First, it never fails. Even when the board falls all the way back to demo flights, the route answers with HTTP 200 and success: true, so you will never see a red row in the Network tab — the fallback is invisible from the outside unless you read the body. Second, the messages that record the fallback are written on the server, not in the browser, so the Console tab has nothing useful for this question.

Why the flights themselves tell you nothing

The obvious instinct is to judge by what is on the board. It does not work here, and it is worth knowing why before you spend twenty minutes on it.

The demo flights are deliberately convincing. They carry real airlines and real-looking numbers — OS 501 on Austrian Airlines, LH 1234 on Lufthansa, LX 456 on Swiss, W6 2345 on Wizz Air — with terminals, gates and baggage belts filled in. A flight number is therefore the worst possible clue.

Their times are not fixed either. Every demo flight is generated fresh against the current clock at the moment of the request, so a departure sits twenty-five or thirty-five minutes out no matter when you look. The board will never appear frozen because of them. Their statuses are mixed as well: some are scheduled, one is airborne with a fifteen-minute delay, and on an arrivals board some have already landed. There is no giveaway row of identical on-time entries.

The Last updated stamp in the footer is equally useless as evidence. It is set whenever a response arrives, regardless of what that response contained.

What actually causes demo flights

There are exactly five. Nothing else in the product switches the board to demo data.

Note what is not on that list. The flight route never reads your subscription status. An expired, cancelled or past-due subscription does not switch the board to demo flights, and paying an outstanding invoice will not change what the screen shows. Subscription status governs feature access — extra slides, weather, analytics, branding — and the public API, not the flight board.

The yellow Demo Mode badge in the display footer is tied to demo: true, which means it only ever appears on the demo board. In the four cases that actually bring you here, the screen carries no marking at all. Its absence proves nothing; use the Network test instead.

Symptoms that are not demo data

If the response says the data is real and the board still looks wrong, one of these is usually the reason.

The flights are real but old. When the call to the flight provider fails — an expired key, a provider outage, a timeout — the system does not jump straight to demo data. It first serves the last successful result, which is kept for up to twenty-four hours. So the board keeps showing genuine flights from a genuine airport, just increasingly out of date. This is why an *invalid* API key behaves differently from a *missing* one: a missing key gives you demo flights immediately, while a wrong one gives you yesterday's real flights until that cache runs dry.

The board doesn't seem to refresh. How often flight data is refetched depends on the plan: sixty minutes on Basic, thirty on Pro, five on Premium. An account with no recognised plan gets sixty minutes. On Basic, an hour of no visible change is exactly what the plan does, and it is the single most common reason someone concludes the screen is stuck on canned data.

The airport is wrong, but the flights are real. If a hotel has no airport configured, the board does not fall back to demo data — it falls back to Vienna and fetches real Vienna departures. Guests reporting flights to airports nobody in the building is flying to are usually seeing this. Airports live under Portal → Airports, where your plan includes one and further ones can be added; which of them a given screen shows is chosen in the display editor under Airport and time.

The screen is showing another screen's settings. Airport, hotel name and layout are configured per screen now, and the display URL carries the screen it belongs to as ?display=<displayId>. Open /display/<hotelId> without that parameter and the board loads whichever active screen was configured most recently — real flights, correct in themselves, from the wrong screen's airport. Copy the URL from the portal rather than typing it: Portal → Displays has a copy icon on each row, and Portal → Displays → open the screen → Preview & URL shows the same address in the Display URL field. When a custom domain is verified, that address is simply https://<your-domain> instead.

The board is empty rather than fake. A screen switched off with the power icon on its row under Portal → Displays returns an empty board flagged inactive: true. Nothing is wrong with the data path; the screen is off.

Check the portal before you walk to the screen

Portal → Displays answers "is this screen showing anything current at all" faster than any browser tooling. Each screen carries a status: Showing, Offline, Never opened for one that exists in the portal but has never had its URL loaded on a device, and Switched off for one you deactivated.

Those labels rest on a heartbeat the screen sends every five minutes, and a screen is only called offline after twelve minutes of silence. The gap is deliberate — two missed beats plus a little slack — because a single dropped request during a reload or a brief network blip would otherwise report a perfectly healthy lobby screen as down. It also means a screen you just unplugged will keep reading Showing for a few minutes.

Billing is no longer in the sidebar; it sits in the menu behind your avatar, at Billing, and shows the subscription status there. The page has a single Manage Subscription button that hands you to the Stripe customer portal, where renewals, cancellations and card changes all happen. Worth doing if your subscription genuinely needs attention — just do not expect it to change the flight board.

Self-hosted instances

Two environment variables decide whether real flights are possible at all. AVIATIONSTACK_API_KEY is the credential for the flight provider, and without it every request returns demo flights. POSTGRES_URL is checked even earlier: with no database configured, the route returns demo flights before it ever looks your hotel up.

The flight provider is called from the server, not from the screen. A display device in the hotel network only needs to reach lobbyflight.com over port 443; it never talks to api.aviationstack.com and there is no reason to open anything for it. Outbound access to the provider is needed where the application runs, and that call goes over plain HTTP on port 80.

One more thing to know while self-hosting: if STRIPE_SECRET_KEY is absent, the feature check treats every feature as available. That is convenient locally and confusing if you are trying to reproduce a customer's plan limits.

Confirming real data is also correct

Once the response shows real data, the remaining question is whether it matches reality. Open the official website of the airport the screen is set to and compare flight numbers against the board. They come from the provider's real-time feed and should line up. If they line up but the times do not, the cause is a time zone rather than the data source.

Next steps