canonical: https://jentic.com/apis/airport-web.appspot.com/airportsapi

# Airport Web Appspot airportsapi

airportsapi is a lightweight reference service that returns the human-readable name and official website URL for an airport given its ICAO code. Coverage focuses on airports in Germany, with limited entries elsewhere. The single-endpoint design makes it useful as a low-friction enrichment step inside flight, logistics, or travel-data pipelines that already have ICAO identifiers.

## For AI agents

Resolve an ICAO airport code to the airport's name and homepage URL in a single GET call.

## Scope

Does not handle flight schedules, runway data, IATA codes, or non-German airport coverage - use for ICAO-to-name lookups in Germany only.

## Capabilities

- Resolve any ICAO code to the airport's official name via /airportsapi/v1/airports/{icao_code}
- Retrieve the airport's published website URL alongside its display name
- Enrich flight datasets with human-readable airport labels
- Validate that a four-letter code corresponds to a known German airport

## Use cases

### Flight Data Enrichment

Replace raw ICAO codes in a flight log with the airport's official name and website link. A single GET to /airportsapi/v1/airports/{icao_code} returns both fields, suitable for inline lookups during ETL or display rendering. Best suited to German airport coverage; pair with a global airport dataset for non-German codes.

Example prompt: Look up ICAO code 'EDDF' and return the airport name and website URL

### ICAO Code Validation

Verify that a user-supplied ICAO code matches a known airport before routing it through downstream systems. The API returns a 200 response with metadata for valid codes and a 404 for unknown ones, giving a low-cost validation path. Coverage is concentrated in Germany.

Example prompt: Validate the ICAO code 'EDDM' by calling the API and confirming a 200 response with a non-empty name field

### Agent Airport Lookup via Jentic

Agents resolve ICAO codes to airport names through Jentic without managing the OAuth 2.0 implicit flow or constructing the path manually. Jentic exposes the single GET operation under a natural-language search and handles the path parameter. Useful inside travel itinerary agents and flight summarisers.

Example prompt: Search Jentic for 'look up airport by ICAO code', load the operation, and call it with icao_code 'EDDB'

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /airportsapi/v1/airports/{icao_code} | Look up airport name and website URL by ICAO code |

## Key resources

- **Airports** — Lookup of airport name and website URL by ICAO code

## Why Jentic

- **Setup:** Wiring airportsapi by hand means running Google's OAuth flow for a single ICAO lookup and writing your own retry logic. Through Jentic you install once, import airportsapi from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** airportsapi puts the ICAO code in the URL path (/airports/{icao_code}) and exposes a single read-only GET, so the agent looks up airports by code and can do nothing else. There are no write operations to grant.
- **Credential handling:** Your airportsapi OAuth token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'look up airport by ICAO code', and Jentic returns the single GET operation with its icao_code path schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Airport Data API** — Global airport metadata including IATA codes, coordinates, and city names
- **Airport Gap API** — Worldwide airport lookup plus distance calculations between airports
- **Flightradar24** — Live flight tracking that consumes ICAO codes alongside real-time movement data

## FAQ

### What authentication does the airportsapi use?

The spec declares Google OAuth 2.0 implicit flow under a security scheme called google_id_token. In practice the public endpoint is reachable for read-only ICAO lookups; through Jentic, any required token is held in the credential vault and supplied at execution time.

### Which airports are covered by the airportsapi?

Coverage is heavily focused on Germany. ICAO codes for German airports such as EDDF (Frankfurt), EDDM (Munich), and EDDB (Berlin Brandenburg) return reliable name and website data. Non-German codes may return 404.

### What are the rate limits for the airportsapi?

The service is hosted on Google App Engine and applies its standard quota tiers. The public spec does not document a numeric limit; expect HTTP 429 or 503 if a single client issues bursty traffic. Treat 429 as a backoff signal.

### How do I look up an airport name through Jentic?

Install with pip install jentic, then use the async client to search for 'look up airport by ICAO code', load the airportsapi GET operation, and execute with icao_code as the path parameter.

### Can I retrieve runway, terminal, or schedule data with this API?

No. The single endpoint returns only the airport name and website URL. For runway counts, terminals, IATA codes, or live flight data, pair with AirportData or Flightradar24.

### Can I limit what my agent is allowed to do with the airportsapi?

Yes. Because Jentic One is self-hosted, you decide in your own rules which operations and credentials the agent may use. This API exposes a single read-only GET that resolves an ICAO code to an airport name and website URL via /airports/{icao_code}, so the agent can only look up airports by code and nothing else. There are no write operations to grant, and your OAuth token is supplied at execution time rather than exposed to the agent.