Skip to content

BUILT FOR DEVELOPERS

One API. Clear documentation.

ADS-B observations, recorded flight history and persistent tail-number subscriptions. Publicly available upcoming schedules are provided separately.

REST · JSON · WebSocket · OpenAPI 3.1

Worldwide tracking, per aircraft

Subscribe to a tail number using PUT /v1/subscriptions/{tail}. The collector follows that registration worldwide, without selecting a region. Remove it with DELETE /v1/subscriptions/{tail}. Monthly plans include 200 tails for $10, 1,000 for $50 or 5,000 for $100.

New subscriptions enter the collection queue within approximately 30 seconds, then wait their turn. Registrations shared by several customers are collected once per cycle. Worldwide tracking depends on observation availability. With a default 3-second request gap, more subscriptions increase collection latency. Spatial searches query stored observations; they do not trigger a regional or worldwide scan.

Account access

Create your account at /login, confirm the one-time email link and sign in. Your private workspace at /app includes API key generation and a Test API action. No password is required. Links expire after 15 minutes; sessions last 7 days.

Authentication & limits

Send your private key in the X-API-Key header. Generate a free key in your verified workspace: 1,000 requests per UTC day, 2 requests/second, 5 aircraft subscriptions, valid for 30 days. Operators can also create keys using flightinfo key-create. HTTP 429 indicates a limit was reached; respect the Retry-After response header.

Download the OpenAPI 3.1 specification for Swagger UI, Postman or a client generator. All documentation content works without JavaScript. Optional analytics is loaded only with consent.

Loading example…

Demo and free-key traffic share an additional per-IP limit: 2 requests/second, burst 5, 1,000 requests/day UTC. Key rotation does not reset usage or subscriptions. Reverse proxies may share an IP budget.

Public interactive demo

Open the playground without an account: five fixed tail numbers, live WebSocket snapshots, recorded tracks, altitude chart, available schedules and a REST request runner. Public endpoints: GET /v1/demo/fleet, GET /v1/demo/plans?limit=10, GET /v1/demo/tails/{tail}/track?from=RFC3339, and wss://flightrouteapi.com/v1/ws/demo. Demo tails: SP-LVD, SP-LVA, SP-LVB, N14011, N776AV. Fleet changes are disabled. History starts when collection begins. Existing demo IP and shared key limits apply.

Position demo WebSocket

The position demos use wss://flightrouteapi.com/v1/ws/demos/positions (or /v1/ws/demos/positions-extended). Each snapshot contains dataset, status, data, stale, checked_at, fetched_at, type and generated_at. Delivery is every 10 seconds; the upstream cache refreshes about once a minute. These are fixed regional samples, separate from private tail subscriptions. External clients use X-API-Key. Same-origin public demo pages use the configured public demo credential server-side. Stream, request and demo IP limits apply.

Fleet WebSocket: subscribe to 10 aircraft

WebSocket /v1/ws/subscriptions requires X-API-Key during the handshake and sends snapshots every 10 seconds. Each snapshot after the first consumes one request. Reconnect after one hour. Use a server-side client or BFF; browser WebSocket clients cannot set arbitrary headers.

Use a key allowing at least 10 subscriptions and enough daily requests. Free keys support 5 aircraft and 1,000 daily requests; a continuous stream consumes approximately 8,640 requests/day plus REST calls. Each message contains your key's complete fleet, not only changed aircraft. The same observation may appear in successive snapshots.

Add each aircraft with PUT /v1/subscriptions/{tail}, then connect once. Additions and removals appear in the next snapshot without reconnecting. Lists belong to the API key, not the individual connection. Use GET /v1/subscriptions to inspect your list.

curl -X PUT https://flightrouteapi.com/v1/subscriptions/SP-LVD \
  -H "X-API-Key: $FLIGHTROUTE_API_KEY"
# Repeat for your other nine registrations.

Node.js server-side client (npm install ws):

import WebSocket from 'ws';

const key = process.env.FLIGHTROUTE_API_KEY;
if (!key) throw new Error('Set FLIGHTROUTE_API_KEY');
const ws = new WebSocket(
  'wss://flightrouteapi.com/v1/ws/subscriptions',
  { headers: { 'X-API-Key': key } }
);
ws.on('message', raw => {
  const snapshot = JSON.parse(raw.toString());
  for (const item of snapshot.data) {
    console.log(item.tail, item.stale, item.aircraft);
  }
});
ws.on('error', error => console.error(error.message));
ws.on('close', (code, reason) => console.log(code, reason.toString()));

The ws library replies to protocol pings automatically. Production clients should reconnect with exponential backoff and jitter, respect HTTP 429 Retry-After, and stop retrying invalid credentials. Connections close after one hour. Streams do not replay every historical point: recover recorded tracks through the REST history API.

Missing observation: {"tail":"SP-LVD","aircraft":null,"stale":true}. Available observations expose lat, lon, observed_at and optional measurements. Evaluate freshness using observed_at, not the snapshot's generated_at. This is not a flight-schedule stream.

Latest historical flights per aircraft

Open the flight history table, enter a private API key and one or more tail numbers. The key is kept only in page memory, not browser storage.

Request the last five observed flight segments for one registration or for each registration in a batch. This requires your private API key. The limit applies separately to each tail, with newest segments first.

curl 'https://flightrouteapi.com/v1/tails/SP-LVD/flights?limit=5' \
  -H 'X-API-Key: YOUR_API_KEY'

curl 'https://flightrouteapi.com/v1/flights/history?tails=SP-LVD,N14011&limit=5' \
  -H 'X-API-Key: YOUR_API_KEY'

Responses contain data: [{tail, flights: [...]}]. Default window: last 30 days. Optional from and to are RFC3339 UTC timestamps (maximum 31 days per request). Up to 20 tails and 1–50 segments per tail. Empty arrays mean no stored airborne observations for that tail and window.

Segments are inferred from stored ADS-B observations. Ground transitions, aircraft identity changes and observation gaps longer than 30 minutes separate segments. completed means ground transitions were observed at both ends; incomplete has missing boundaries; unconfirmed is the last segment without an observed landing. Times are first/last airborne observations, not exact departure or arrival times. Callsigns are not guaranteed commercial flight numbers; takeoff and landing events now provide estimated midpoint times and bounds. Airport matches use a ground observation within 5 km of a reference point; similarly close alternatives are rejected. These are estimates, not airline confirmation. The nullable completed field is true after an observed landing and null when the outcome is unknown. Sparse coverage may split one actual flight into multiple segments. IDs may change with query boundaries or backfill.

This endpoint includes imported archives where available. An hourly background job resumes the three-year archive import for subscribed aircraft. Daily archives may be published later; a request does not trigger backfill. Archived query points are sampled at 60-second intervals with state changes preserved; original traces are retained separately. Collection coverage and import progress determine availability. Over 100,000 observations returns HTTP 422; narrow the window or reduce the number of tails.

Data & freshness

Altitude is in ft, speed in kt, heading in degrees, and vertical rate in ft/min. All timestamps use UTC. stale indicates an old or missing observation. History contains observations recorded since collection began; default retention is 30 days. Source coverage and update frequency vary.

Upcoming schedules

Use GET /v1/subscriptions/plans or GET /v1/tails/{tail}/plans for a subscribed aircraft. The job checks public profiles every 30 minutes by default, using available schedule integrations. no_upcoming_visible means no schedule is visible; unavailable means the source failed. Inspect stale and last_success. An empty result does not prove that no flights are planned. Schedule data is separate from ADS-B data and its license.

Endpoints