Data loss between FlightXML and AeroAPI

I’ve found some issues in the process of migrating from FlightXML2 to AeroAPI.
an example result from FlightXML2/SearchBirdseyeInFlight:

    {
        "faFlightID": "FD467-1692145623-fds-1627p",
        "ident": "FD467",
        "prefix": "",
        "type": "BE20",
        "suffix": "",
        "origin": "YBRK",
        "destination": "YBBN",
        "timeout": "0",
        "timestamp": 1692161029,
        "departureTime": 1692157211,
        "firstPositionTime": 1692156971,
        "arrivalTime": 0,
        "longitude": 152.87279,
        "latitude": -27.03557,
        "lowLongitude": 150.47385,
        "lowLatitude": -27.03557,
        "highLongitude": 152.87279,
        "highLatitude": -23.37305,
        "groundspeed": 222,
        "altitude": 98,
        "heading": 178,
        "altitudeStatus": "",
        "updateType": "A",
        "altitudeChange": "D",
        "waypoints": "-27.384 153.12"
  }

and the equivalent result with aeroapi/flights/search:

    {
      "ident": "FD467",
      "ident_icao": "FD467",
      "ident_iata": null,
      "fa_flight_id": "FD467-1692145623-fds-1627p",
      "actual_off": "2023-08-16T03:40:11Z",
      "actual_on": null,
      "foresight_predictions_available": false,
      "predicted_out": null,
      "predicted_off": null,
      "predicted_on": null,
      "predicted_in": null,
      "predicted_out_source": null,
      "predicted_off_source": null,
      "predicted_on_source": null,
      "predicted_in_source": null,
      "origin": {
        "code": "YBRK",
        "code_icao": "YBRK",
        "code_iata": "ROK",
        "code_lid": null,
        "timezone": "Australia/Brisbane",
        "name": "Rockhampton",
        "city": "Rockhampton",
        "airport_info_url": "/airports/YBRK"
      },
      "destination": null,
      "waypoints": [],
      "first_position_time": "2023-08-16T03:36:11Z",
      "last_position": {
        "fa_flight_id": "FD467-1692145623-fds-1627p",
        "altitude": 98,
        "altitude_change": "D",
        "groundspeed": 222,
        "heading": 178,
        "latitude": -27.03557,
        "longitude": 152.87279,
        "timestamp": "2023-08-16T04:43:49Z",
        "update_type": "A"
      },
      "bounding_box": [
        -23.37305,
        150.47385,
        -27.03557,
        152.87279
      ],
      "ident_prefix": null,
      "aircraft_type": null
    }

There are fields that are empty in AeroAPI, that I require for my specific use case. They are the “destination” and “aircraft_type” fields.
These are obviously accessible to FlightXML so its not a case of the information not existing.
Is this a known issue? And would I be able to expect this to be solved in the near future, especially considering the end of service of FlightXML?

Also am I right to assume AeroAPI::actual_off is equivalent to FlightXML::departureTime ?
After epoch conversion they seem to be the same times, but I couldn’t find a definitive answer.

Edit: phrasing

I do not seem to see a v4/AeroAPI key under your user account. Which user account are you using v4/AeroAPI under? My speculation is that this account has a subtractive ACL (Access Control List) for Australian data.

This is the client account that was used.

It appears that when setting up the account a selection had been made that resulted in some data not being presented. If the resulting product/service that is incorporating the data is for internal purposes then we can enable the the missing data.

Below is the statement that was presented and the selection was not checked and therefore resulted in the missing data.

I will be using AeroAPI data for personal use or internal business purposes and want to include data from Airservices Australia. I acknowledge that commercialization (e.g., resale, redistribution) and external use is prohibited, including for B2C purposes. If this option is not selected:

  1. AeroAPI will still provide Terrestrial ADS-B position data in Australia within AeroAPI.
  2. The opt-out of Australia data is account-wide and will affect all FXML keys on your account.