Walk onto a modern flight deck and you'll see a tablet clipped beside each pilot. That's an Electronic Flight Bag, or EFB — the device that replaced the 40-pound leather kitbag of paper charts, manuals, and checklists pilots used to lug through the terminal. But an EFB is only as good as the data flowing into it, and behind every chart and weather layer on that screen is an API. This post explains what an EFB actually does and maps each of its features to the data feed that powers it.
What an EFB is (and what it replaced)
An EFB is a device — usually a tablet running an app like ForeFlight or Jeppesen FliteDeck — that holds and displays the information a pilot needs to plan and fly. It replaced a literal bag of paper: approach plates, en-route charts, airport diagrams, aircraft manuals, and performance tables. Regulators classify them loosely as portable (a tablet you carry on) or installed (wired into the aircraft), but for most pilots "EFB" means the app on the iPad.
The value isn't just weight saved. A paper chart is static from the moment it's printed; an EFB updates, overlays live weather, shows your aircraft's position on the plate, and recomputes a plan when the route changes.
What an EFB actually does
Strip an EFB down to features and you get a checklist of distinct capabilities — each backed by its own data source:
- Charts and plates — approach procedures, departures (SIDs), arrivals (STARs), and airport diagrams.
- Weather — METARs, TAFs, radar, and winds aloft for planning and en route.
- Flight planning and a moving map — routing, with the aircraft's live position shown on the chart.
- NOTAMs and TFRs — operational notices and temporary airspace restrictions along the route.
- Airport and navaid data — runways, frequencies, elevations.
- Weight, balance, and performance — takeoff and landing distances for the aircraft and conditions.
The APIs behind each feature
Here's the part developers care about: every one of those features is a data feed, and if you're building an EFB — or adding EFB-style features to an app — you wire each to an endpoint rather than sourcing and decoding raw aviation data yourself. Mapped to SkyLink API:
| EFB feature | Data API |
|---|---|
| Approach plates, SIDs, STARs, airport diagrams | Aerodrome charts (GEN / GND / SID / STAR / APP) |
| METAR / TAF weather | Weather |
| Winds and temperatures aloft | Winds aloft |
| NOTAMs and TFRs | NOTAMs |
| Runways, frequencies, navaids | Airports |
| Takeoff/landing performance | Aircraft performance |
| One-call preflight summary | Flight briefing |
A single chart fetch, for example, is one call that returns categorized PDF links for an airport:
curl "https://skylink-api.p.rapidapi.com/charts/EGLL" \
-H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
-H "X-RapidAPI-Host: skylink-api.p.rapidapi.com"
Why build on an API instead of raw sources
Aviation data is scattered across national authorities, in formats built for teletype rather than apps. An approach plate lives in one country's AIP; METARs come as coded strings; NOTAMs arrive as cryptic abbreviations; winds aloft are packed into ddfftt groups. Sourcing, normalizing, and keeping all of that current across the world is a full-time job. An aggregating API collapses it into one authenticated integration with decoded, consistent responses — which is why most EFB-style products build on a data provider rather than the raw feeds.
Several of these features have their own deep-dives worth reading if you're building them: METAR and TAF for weather, winds aloft for the wind grid, TFRs for airspace restrictions, and how runways are numbered for the airport data underneath.
SkyLink API gives you a free tier of 1,000 requests/month to prototype EFB features against — charts, weather, NOTAMs, airports, and performance behind one key — with paid plans starting at $19/mo for production. It's available through the free trial — sign up, grab a key, and build the flight bag, not the plumbing.