Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/danizd/GeoSentinel/llms.txt

Use this file to discover all available pages before exploring further.

The Military Flights endpoint does not query OpenSky directly. Instead, the GeoSentinel backend proxies the request to the military-relay microservice running on port 8002, which maintains its own rate limiter, bbox cache, and hex-database filter against the OpenSky Network ADS-B feed. The backend computes the union bounding box across all active AOIs in the database and issues a single request to the relay at GET /api/military/v1/list-military-flights, avoiding the serialization bottleneck that arises from sending one request per AOI. Results include per-flight trail history (up to the last 5 positions) assembled by the relay’s in-memory flight_history store, and a staleness flag derived from the X-Stale response header the relay sets when it falls back to cached data.

GET /v1/military-flights

Returns all military aircraft currently visible within the union bounding box of every active Area of Interest. No query parameters are accepted — bounding box coordinates are derived automatically from the active AOI records in the database.

Response body

The response conforms to MilitaryFlightsResponseDTO.
flights
array
required
List of military aircraft currently tracked within the AOI union bounding box. Each element is a MilitaryFlightDTO object.
clusters
array
required
Groups of 3 or more aircraft within 100 km of each other, computed by the relay using a haversine-distance pass over the current flights list. Each element is a MilitaryFlightClusterDTO object.
isStale
boolean
required
true when the relay returned an X-Stale: true response header, indicating it served data from its bbox cache rather than a fresh OpenSky fetch. Clients should display stale data with a visual warning.

Example request

curl http://localhost:8000/v1/military-flights

Example response

{
  "flights": [
    {
      "id": "abc123:1736942400",
      "callsign": "RCH210",
      "hexCode": "AE1234",
      "location": {"latitude": 48.5, "longitude": 2.3},
      "altitude": 35000,
      "heading": 270,
      "speed": 480,
      "lastSeenAt": "2025-01-15T12:00:00Z",
      "aircraftType": "C17",
      "aircraftModel": "Boeing C-17 Globemaster III",
      "operator": "US Air Force",
      "operatorCountry": "United States",
      "registration": null,
      "origin": null,
      "destination": null,
      "isInteresting": false,
      "trail": [[2.1, 48.3], [2.2, 48.4], [2.3, 48.5]],
      "source": "opensky"
    }
  ],
  "clusters": [],
  "isStale": false
}
If no AOIs are marked active in the database, the backend skips the relay call entirely and returns an empty MilitaryFlightsResponseDTOflights and clusters will both be empty arrays and isStale will be false.
The military-relay microservice requires two environment variables to authenticate with the OpenSky Network API: OPENSKY_CLIENT_ID and OPENSKY_CLIENT_SECRET. Without valid credentials the relay will fail to fetch live state vectors. The relay runs as a separate process on port 8002, and the backend resolves it via the MILITARY_RELAY_URL environment variable (default: http://military-relay:8002).

Build docs developers (and LLMs) love