Skip to content
DevOps
Back to blog
Breaking change

Data API /all endpoints are being deprecated

We are replacing every /all endpoint in the Data API with pagination to reduce per-request work and response sizes. Removal is currently planned for 21 November 2026, subject to change.

Fred Cardoso

We are deprecating all /all endpoints in the Data API and replacing them with paginated alternatives to improve performance.

We currently plan to remove them on 21 November 2026, though the date is provisional and subject to change. The /all endpoints will remain available during the transition as their paginated replacements become available.

Why pagination?

An /all request returns an entire collection. As that collection grows, the API has more data to retrieve, transform and serialise. Larger responses also take more bandwidth and memory to process, especially when records include map geometry.

Pagination limits the records returned in each response. The aim is to reduce payload sizes and work per request, with more predictable performance for the API and its clients.

Fetching every page still downloads the full collection, split into batches. Applications that only need part of it can avoid downloading the rest.

Pagination across collection endpoints

The release we’re preparing covers these eight collection routes:

  • ATC positions: /v2/ATCPositions
  • Special areas: /v2/specialAreas
  • Aircraft: /v2/aircrafts
  • Airports: /v2/airports
  • Subcentres: /v2/subcenters
  • NOTAMs: /v2/notams
  • Virtual airlines: /v2/virtualAirlines
  • Creators: /v2/creators

These changes are still being prepared. Check each endpoint’s documentation and production availability before changing your integration. Some routes already support pagination; we’re adding replacements where needed and applying consistent limits across all eight.

The existing /all routes keep their full-array responses for now. We’ll remove them in a separate step.

What changes for API clients?

An ATC positions request currently looks like this:

GET /v2/ATCPositions/all

With pagination:

GET /v2/ATCPositions?page=1&perPage=25

All eight routes use these page-based pagination limits:

  • page starts at 1 and defaults to 1.
  • perPage defaults to 25, with a maximum of 100.
  • Both parameters must be positive safe integers, and the calculated offset must stay within the supported range. Invalid values, repeated pagination parameters and unsafe offsets return HTTP 400.

Records use a stable ascending order: icao for airports, icaoCode for aircraft, userId for creators and id for the other collections listed above.

The /all routes return a bare array. Paginated responses contain:

  • items: the records on the requested page.
  • totalItems: the total number of matching records.
  • page: the requested page number.
  • perPage: the requested page size.
  • pages: the total number of pages.

An empty collection returns:

{
  "items": [],
  "totalItems": 0,
  "page": 1,
  "perPage": 25,
  "pages": 0
}

If you need the whole collection, read the records in items and use the pagination metadata to fetch the remaining pages.

Keeping the options you need

Existing filters and options remain available. ATC positions, special areas, subcentres and NOTAMs support mapType=regionMap or mapType=regionMapPolygon; omit this option to include both map representations.

To include airport information with ATC positions, use loadAirport=true. For runways in airport responses, use includeRunways=true. Both default to false. For special areas and NOTAMs, now=true applies the existing active-window rules; now defaults to false.

Check each endpoint’s documentation for its filters, and only request the extra data you need. Existing public access and authentication requirements are unchanged, as are JSON/Aurora response support and cache lifetimes.

Preparing your integration

  1. Find every Data API call that uses an /all endpoint. Include background refreshes and scheduled imports.
  2. Switch to each documented paginated replacement once it’s available, using your existing authentication. If you already use a paginated route, check its defaults, page-size limit and validation rules.
  3. Update your response handling to read each page’s records and metadata. Fetch the remaining pages when you need the full collection.
  4. Test empty results, the final page, invalid parameters and failed requests. If you keep a local copy, allow for records changing whilst you fetch pages. Pagination does not guarantee a snapshot.
  5. Plan to finish migrating away from /all before the current 21 November 2026 removal target, and check for timetable changes.