Flight changes in n8n, without polling.
FlightByte watches the flight and sends one signed webhook per change, listing exactly what changed. Your n8n workflow receives it, verifies it and decides who to tell. No Schedule Trigger, no table of old values to compare.
- • Departure gate is now D12
- • Departure time (estimated) is now 14:00, was 14:10
- • Arrival time (estimated) is now 17:45, was 17:55
Two templates, free to import
Both use only n8n’s built-in nodes and run on n8n Cloud or any self-hosted n8n 2.x with a public HTTPS address. Delete the channels you do not need.
Flight change alerts
A form adds a flight. Every change goes to Slack. Gate, time, delay, cancellation and diversion go to the passenger by email, and cancellations, diversions and arrival delays of an hour or more by SMS too.
- Slack
- Email · SendGrid
- SMS · Twilio
Airport pickup
A form books a pickup. The driver gets a text when the flight leaves, when the landing time moves, when it reaches the gate, which belt the bags are on, or when it is cancelled or diverted.
- SMS or WhatsApp · Twilio
Why there is no Schedule Trigger
The usual flight-alert workflow polls a flight API on a timer, keeps the last known values in a table and computes the difference itself. Most of its nodes exist to find out whether anything happened.
Polling from n8n
8 nodes- Schedule Trigger · every 30 minutes
- Read the watched flights · Postgres or Sheets
- Call the flight API · one request per flight
- Read the last known values · per flight
- Compare old and new · Code node
- Write the new values back · per flight
- If something changed · most runs: nothing
- Send the alert · finally
A gate change waits for the next run, up to half an hour, and every run costs a request per flight whether it changed or not.
With FlightByte
5 nodes- Webhook · raw body on
- Verify the signature · Crypto, HMAC-SHA256
- Answer 204 · before any message
- Route by event type · Switch
- Send the alert · Slack, email, SMS
FlightByte polls on its side, closer together near departure and landing, works out the diff, and sends only what changed.
The arithmetic behind leaving the timer out: why polling a flight API costs more than you think.
What reaches your webhook
One flight.updated event per change, with the full flight and a changes list that says what moved, from what, to what. Times are UTC; the templates print them in each airport’s own time zone.
1{2 "id": "evt_9c2e41b7-3d0a-4f6e-8b1c-5a7d2e9f0c34",3 "type": "flight.updated",4 "subscriptionId": "sub_7fd9fa92faf3475db99b",5 "flightKey": "TK1:2026-10-21@IST-JFK",6 "flight": { "...": "the full flight snapshot" },7 "changes": [8 {9 "type": "departure.gate.changed",10 "path": "departure.gate",11 "from": "D10",12 "to": "D12",13 "message": "Departure gate changed from D10 to D12"14 },15 {16 "type": "departure.estimated.changed",17 "path": "departure.times.estimatedGate",18 "from": "2026-10-21T11:10:00Z",19 "to": "2026-10-21T11:00:00Z",20 "deltaMinutes": -10,21 "message": "Departure estimated gate time changed from 2026-10-21T11:10:00Z to 2026-10-21T11:00:00Z"22 }23 ],24 "metadata": { "bookingRef": "BK-1042" }25}
The alerts template routes four event types. Contact details never leave n8n: the passenger’s email and phone sit in an n8n data table keyed by subscription id, and FlightByte only sees the booking reference you put in metadata.
flight.updated- Something about the flight changed. The passenger is looked up and told by email and SMS according to the rules, and Slack hears every change.
subscription.test- A line in Slack, so you can see the path works before the flight does anything.
subscription.suspended- A warning in Slack. FlightByte stops after twenty failed deliveries, and one call resumes it.
subscription.completed- The flight is over. The passenger's row is deleted from the n8n data table.
Set it up in five steps
The short version. The step-by-step guide covers each node, the test event and what to do when the form says no.
Import the workflow
In n8n, open a new workflow, choose Import from URL in the workflow menu and paste:
https://flightbyte.dev/n8n/flight-change-alerts.json
Make up a signing secret
Every flight the workflow watches is signed with the same secret, so one webhook serves them all.
echo "whsec_$(openssl rand -hex 24)"
Connect FlightByte
Create a Custom Auth credential on Watch the flight. The header authenticates the request; the body is merged into every subscription, so FlightByte signs that flight’s webhooks with your secret.
{ "headers": { "x-api-key": "fb_live_..." }, "body": { "secret": "whsec_..." }}
Give the webhook the same secret
Create a Crypto credential on Sign the raw body and paste the same whsec_... value as its HMAC secret.
Connect the channels and publish
Pick the Slack channel, set the email and SMS senders, and publish. Open the form, enter a flight, and the done page shows the subscription id. Send a test event to it and Slack answers within a second.
Questions n8n builders ask
Does it work with self-hosted n8n?
localhost and on private or loopback ranges, so set WEBHOOK_URL on your instance; the workflow builds each subscription's webhook URL from it. n8n Cloud works as it is.Do I need to install a community node?
How does the workflow know the webhook really came from FlightByte?
x-flightbyte-signature. The workflow recomputes it with a Crypto node, rejects anything that does not match or is more than five minutes old, and drops retries it has already handled by event id.Can bookings come from Google Sheets, Airtable or my own system instead of the form?
Build the request node. Everything after the subscription stays as it is.What if the airline has not published the flight yet?
What does it cost?
Other integrations
Watch your first flight from n8n tonight.
A free key, the template and two credentials. The first 3 flights each month cost nothing.
A free key in a minute, no card. Paid plans are paid by card in the dashboard.