SUPPORT CENTER

Assumptions

• The aircraft has equipment that automatically logs flight data and uploads it to the CloudAhoy server.
• Each flight is captured in the scheduler.

Workflow

The workflow from a user perspective is:

1. Pilot flies
2. Upon return, the pilot can immediately debrief their flight using their CloudAhoy account or an institution account such as a student record.

The workflow from a process perspective is:

1. The pilot dispatches a flight that has been defined in a scheduling system.
2. The pilot performs a flight.
3. Upon return, flight data is automatically uploaded to CloudAhoy.
4. CloudAhoy sends a request to the scheduler asking who was on board (participants).
5. The scheduler responds from the scheduler with a list of pilots on the flights (participants).
6. CloudAhoy stores the participant’s information in the Pilot and Co-pilots fields, enabling two participants to access the debrief through their CloudAhoy account.

Calling the API Flow

The flow for calling the API is as follows:

• All requests are initiated from CloudAhoy.
• Requests should be handled synchronously.
• One or more participant pilots can be returned. However, only the first two will be stored as the flight’s owners, as pilot as co-pilot (with the appropriate roles).

Request from CloudAhoy to Scheduler

Requests from Cloudahoy to a scheduler will be POSTed to an agreed-upon endpoint and will occur synchronously. Requests from CloudAhoy will include an Authorization header, which provides an access token to identify the organization for which the request is being made.

Authorization: Bearer <org's access token>

The scheduler provides the appropriate org access token to the CloudAhoy development team. The token's contents (and semantics) are under the scheduler's control. CloudAhoy will provide it with any request triggered by one of the organization’s pilots or aircraft.

Request Body

Sample JSON Request

{
    "tail": "N12345",
    "takeoff": 1598015580,
    "landing": 1598019936,
    "url": "https://www.cloudahoy.com/debrief/?key=j6rRAr9sPbxwaUG3A"
}

Response from Scheduler to CloudAhoy

A successful response will return a JSON payload with a 200 status code. This response must occur synchronously.

Response Body

Participants Object

Where “role” is:

Sample JSON Response

This is a sample response for a dual cross-country flight with a student and an instructor onboard.

{
    "comment": "Student pilot on dual cross-country",
    "missionId": "2a242af09ef1",
    "participants": [
        {
            "email": "drew@cloudahoy.com",
            "firstName": "Drew",
            "lastName": "Carden",
            "role": "Student"
        },
        {
            "email": "chris@cloudahoy.com",
            "firstName": "Chris",
            "lastName": "Hufford",
            "role": "Instructor"
        }
    ]
}

Acceptable HTTP Response Codes

Notes and Troubleshooting

CloudAhoy sends a request only when a flight is being imported into CloudAhoy. However, some scenarios need to be considered when setting up this integration. It is possible to receive multiple requests for the same dispatch.

• CloudAhoy may send multiple requests for a single flight.
  • This can happen when only part of the original flight was transmitted, and another transmission happened with appended data.
  • In these cases, the debrief link will change, but the takeoff time will remain the same.

• CloudAhoy may send multiple requests for a single dispatch.
  • Most automated systems send data after avionics have been turned off; this may result in CloudAhoy having two or more debriefs for a single dispatch.
  • This scenario is common on cross-country flights.
  • In these cases, the takeoff times will be different for each flight.