Flight Types

Role names and user_group_id values are listed in User groups.

Company-specific flight type definitions. Used to classify flights by purpose and determine logbook time allocation.

---

Flight Classification Values

Value	Description	Logbook rollup
pic	Pilot in Command	PIC total
picus	Pilot in Command Under Supervision	Counts toward PIC total; also reported separately
sic	Second in Command	SIC total — only counts on multipilot aircraft
fi	Flight Instructor	Counts toward PIC and FI totals; also reported separately
dual	Dual Received	DUAL total
cri	Class Rating Instructor	Counts toward PIC and FI totals; also reported separately
iri	Instrument Rating Instructor	Counts toward PIC and FI totals; also reported separately
fifi	Flight Instructor of Flight Instructors	Counts toward PIC and FI totals; also reported separately
sfi	Synthetic Flight Instructor	Counts toward PIC and FI totals; also reported separately
tri	Type Rating Instructor	Counts toward PIC and FI totals; also reported separately
exa	Examiner	Counts toward PIC and FI totals; also reported separately
sup	Supervisor	Reported separately only — not rolled into PIC or FI
none	None	Not logged

These values apply to pic_flight_time, sic_flight_time, and supervisor_flight_time, which determine how logbook time is allocated to the flight’s PIC (pic_id), SIC (sic_id), and Supervisor (supervisor_id) respectively.

Migration note: copic (Copilot) is deprecated and removed. All existing copic configurations were migrated to sic. To preserve the original semantics, sic time is only credited on multipilot aircraft (Aircraft.multipilot = true); on single-pilot aircraft sic time is not logged. Do not send copic — it is no longer accepted as a classification key.

Migration note: tre (Type Rating Examiner) was renamed to exa (Examiner) — same meaning, same rollup, generic key not tied to type ratings. Existing tre configurations were migrated to exa. Do not send tre; it is no longer returned by the API and no longer counts toward any total.

PIC / FI rollup: picus, cri, iri, fifi, sfi, tri, exa all count toward a pilot’s PIC total time. The instructor/examiner classes (cri, iri, fifi, sfi, tri, exa) additionally count toward the FI total time — picus does not (it is PIC time only). Each is also exposed as its own line in pilot statistics so the time worked in each function can be seen separately. sup is the exception: it is reported separately only and never rolled into PIC or FI.

---

List Flight Types

GET /flight_types/index.json

GET /flight_types/index/true.json

List active (non-deleted) flight types for the company, ordered by order field. Pass true to filter only types with booking: true.

Response

{
  "flightTypes": [
    {
      "FlightType": {
        "id": "5",
        "company_id": "42",
        "name": "Training",
        "color": "#3498db",
        "booking": true,
        "require_frat": false,
        "order": "0",
        "deleted": false
      },
      "Aircraft": {
        "12": "EC-KMH",
        "18": "EC-JMZ"
      }
    }
  ]
}

Aircraft is the fleet restriction as id → registration. It is always present, and an empty value ([]) means the type is unrestricted — see below.

---

List Flight Types (Manager)

GET /flight_types/manager_index.json

List all flight types including soft-deleted ones. Intended for management views.

Response

Same structure as index (including Aircraft), includes all records regardless of deleted status.

---

View Flight Type

GET /flight_types/view/{id}.json

Retrieve a single flight type by ID.

Path Parameters

Parameter	Type	Description
id	number	Flight type ID

Response

{
  "result": {
    "FlightType": {
      "id": "5",
      "company_id": "42",
      "name": "Training",
      "color": "#3498db",
      "booking": true,
      "order": "0",
      "deleted": false
    }
  }
}

---

Create Flight Type

POST /flight_types/manager_add.json

Create a new flight type. Also returns the flightClassification reference data.

Request Body

Field	Type	Required	Description
FlightType.name	string	Yes	Display name
FlightType.color	string	No	Hex color code
FlightType.booking	boolean	No	Available for booking scheduling
FlightType.pic_flight_time	string	No	PIC time classification key
FlightType.sic_flight_time	string	No	SIC time classification key
FlightType.supervisor_flight_time	string	No	Supervisor time classification key. Defaults to none
FlightType.require_frat	boolean	No	Crew dispatching a flight of this type must submit a completed FRAT (frat_score, frat_band, frat_data) — see Dispatch Schedule. Defaults to false

Aircraft restriction (optional)

A flight type can be restricted to a subset of the fleet. The rule is the same “empty means unrestricted” convention used by pilot attributions:

Links	Meaning
none	The flight type can be flown with any of the company’s aircraft
one or more	The flight type can only be flown with those aircraft

An empty list is therefore never “no aircraft allowed”. Listing every aircraft in the fleet and sending no list at all are not the same thing: the explicit list keeps rejecting aircraft added later, the empty one does not.

Send the links as a standard HABTM list alongside the FlightType fields (applies to both manager_add and manager_edit):

Field	Type	Required	Description
Aircraft.Aircraft[]	array	No	Aircraft ids the type is restricted to. When the key is present it replaces the whole set; an empty value clears the restriction. When the key is absent, existing links are left untouched — so a client that predates this feature cannot wipe a restriction it does not know about.

Ids that do not belong to the authenticated company are dropped silently. Inactive aircraft are accepted and kept (parking an aircraft must not widen a restriction); links to deleted aircraft are not returned.

The same links can be written from the aircraft end — POST /aircraft/edit.json accepts FlightType.FlightType[] with identical semantics (key absent = untouched, empty = detach from every flight type, foreign ids dropped), and GET /aircraft/view/{id}.json returns the aircraft’s attributed flight types under FlightType. See Aircraft. Detaching the last aircraft from a flight type makes that flight type unrestricted again — that is the empty-set rule, not a special case.

Example (form-encoded) — restrict to two aircraft:

data[FlightType][name]=OPC Simulator
data[Aircraft][Aircraft][]=12
data[Aircraft][Aircraft][]=18

Clear the restriction (fly with anything):

data[FlightType][name]=OPC Simulator
data[Aircraft][Aircraft][]=

Advisory: the restriction is not enforced by the API. POST /flights/add.json, /flights/edit.json and the schedule endpoints all accept an aircraft outside the list. The warning lives in the web client only, so an API integration that needs the rule applied must check it itself — read Aircraft from this endpoint and compare.

Required certificates (optional)

A flight type can require certificates per seat (pic / sic / supervisor) — for example a training type where the PIC must hold a licence, a class-1 medical and a single-engine rating, while the student SIC only needs a medical. Each seat is independent; an empty list means no requirement for that seat.

A required entry references a certificate type key from UserCertificate.$types (e.g. licence, sep_land_rating, medical_class_1) — the same catalog returned by GET /pilots/certificate_types.json.

To set them, send the following alongside the FlightType fields (applies to both manager_add and manager_edit):

Field	Type	Required	Description
syncRequiredCertificates	boolean	No	Opt-in flag. When present (1) the request owns the requirements: the posted RequiredCertificate list fully replaces the existing one (an empty list clears them). When absent, existing requirements are left untouched.
RequiredCertificate[N].role	string	—	Seat the requirement gates: pic, sic or supervisor.
RequiredCertificate[N].certificate_type	string	—	A certificate type key (e.g. medical_class_1).

Invalid roles/types and duplicate (role, certificate_type) pairs are ignored server-side.

Example (form-encoded):

data[FlightType][name]=Dual
data[syncRequiredCertificates]=1
data[RequiredCertificate][0][role]=pic
data[RequiredCertificate][0][certificate_type]=licence
data[RequiredCertificate][1][role]=pic
data[RequiredCertificate][1][certificate_type]=medical_class_1
data[RequiredCertificate][2][role]=sic
data[RequiredCertificate][2][certificate_type]=medical_class_2

Response

{
  "result": true,
  "flightClassification": {
    "pic": "Pilot in Command",
    "picus": "Pilot in Command Under Supervision",
    "sic": "Second in Command",
    "fi": "Flight Instructor",
    "dual": "Dual Received",
    "cri": "Class Rating Instructor",
    "iri": "Instrument Rating Instructor",
    "fifi": "Flight Instructor of Flight Instructors",
    "sfi": "Synthetic Flight Instructor",
    "tri": "Type Rating Instructor",
    "exa": "Examiner",
    "sup": "Supervisor",
    "none": "None"
  }
}

---

Edit Flight Type

POST /flight_types/manager_edit/{id}.json

PUT /flight_types/manager_edit/{id}.json

Update a flight type. A GET to this endpoint returns the current record data plus usage count.

Path Parameters

Parameter	Type	Description
id	number	Flight type ID

Request Body (POST/PUT)

Same fields as create, wrapped under FlightType.

Response (POST/PUT)

{
  "result": true,
  "message": "The flight type has been saved."
}

Response (GET)

requiredCertificates is the flat list of the flight type’s per-seat requirements (see Required certificates above).

attributedAircraft is the fleet restriction as id → registration, and is [] when the type is unrestricted. It is a map rather than a bare id list so a client can label an aircraft that is missing from its own cached fleet.

{
  "flights": 42,
  "flightClassification": { ... },
  "requiredCertificates": [
    { "role": "pic", "certificate_type": "licence" },
    { "role": "pic", "certificate_type": "medical_class_1" },
    { "role": "sic", "certificate_type": "medical_class_2" }
  ],
  "attributedAircraft": {
    "12": "EC-KMH",
    "18": "EC-JMZ"
  }
}

---

Delete Flight Type

POST /flight_types/manager_delete/{id}.json

DELETE /flight_types/manager_delete/{id}.json

Soft-delete a flight type (sets deleted = 1). Only flight types belonging to the authenticated company can be deleted.

Path Parameters

Parameter	Type	Description
id	number	Flight type ID

Response

{
  "result": true
}

---

Reorder Flight Types

POST /flight_types/manager_reorder.json

Set the display order of flight types. Restricted to managers (user_group_id ≤ 110 — Compliance & Safety Manager and above).

Request Body

Field	Type	Required	Description
items	array	Yes	Array of flight type IDs in desired display order

Response

{
  "result": true
}

---

Certificate Compliance

GET /flight_types/compliance/{id}.json

Report whether a user holds the required certificates to occupy each seat (pic / sic / supervisor) of a flight type. Uses the flight type’s required certificates; a seat with no requirements is always compliant.

A required type is satisfied when the user holds at least one certificate of that exact type that is valid at the evaluated time — issue date empty or in the past, expiration empty or in the future (same rule as the licence-validity check used across the app).

Path Parameters

Parameter	Type	Description
id	number	Flight type ID

Query Parameters

Parameter	Type	Required	Description
user_id	number	No	Target pilot. Defaults to the authenticated user. Allowed for staff (user_group_id ≤ 170 — Flight Instructor and above); a regular pilot or student (Captain and below) passing another user’s id gets 403 Forbidden. The target must belong to the caller’s company.
at	number	No	Unix seconds at which to evaluate certificate validity. Defaults to now. Pass a future time (e.g. a planned flight start) so forward scheduling reflects validity at that moment.

Response

Per-seat breakdown. For each seat: compliant is false when any required type is missing (not held) or expired (held but none currently valid); ok lists the satisfied types. required is the full list configured for that seat. limit is the earliest unix time the seat stops being compliant — the soonest expiration among the satisfied required certs — or null when the seat has no requirements or a required certificate never expires. Combined with a future at, this lets callers warn when a certificate expires before a planned flight.

{
  "result": {
    "flight_type_id": "5",
    "flight_type": "Dual",
    "user_id": "123",
    "at": 1785000000,
    "compliance": {
      "pic": {
        "compliant": false,
        "required": ["licence", "medical_class_1", "sep_land_rating"],
        "ok": ["licence", "sep_land_rating"],
        "missing": [],
        "expired": ["medical_class_1"],
        "limit": 1788220800
      },
      "sic": {
        "compliant": true,
        "required": ["medical_class_2"],
        "ok": ["medical_class_2"],
        "missing": [],
        "expired": [],
        "limit": 1790000000
      },
      "supervisor": {
        "compliant": true,
        "required": [],
        "ok": [],
        "missing": [],
        "expired": [],
        "limit": null
      }
    }
  }
}

Errors

Status	When
404	Flight type not found in the caller’s company, or user_id is not a member of the company
403	A user with user_group_id > 170 (Captain and below) passed a user_id other than their own

Type rating

GET /flight_types/compliance.json?aircraft_id={id}&pic_id={id}&sic_id={id}&supervisor_id={id}&at={unix}&schedule_id={id}

With aircraft_id the answer also carries type_rating: whether that aircraft requires a type rating and which seats of the given crew are covered, by the same rule the booking and dispatch gates apply (see Type rating requirement). The flight type id may then be left out, and compliance is null. Without any crew parameter the target user is checked as PIC. Crew from another company is ignored. schedule_id reports a manager’s override stored on that booking for this crew.

{
  "result": {
    "flight_type_id": null,
    "flight_type": null,
    "user_id": "618",
    "at": 1797325200,
    "compliance": null,
    "type_rating": {
      "required": true,
      "ok": true,
      "aircraft_id": 160,
      "model": { "id": 2009, "label": "CESSNA 172 Skyhawk" },
      "seats": {
        "pic": {
          "user_id": 178, "name": "Antonio Oreilly", "covered": true, "via": "instructor",
          "instructor_id": 306, "instructor_name": "Andrew Flyers",
          "certificate": { "id": "b3f1…", "type": "tri", "name": "TRI C172", "expiration": "2029-01-01" }
        }
      },
      "uncovered": [],
      "overridden": false,
      "override_reason": null,
      "can_override": true
    }
  }
}

Field	Description
required	The aircraft requires a type rating. When false, nothing else is meaningful.
ok	Every checked seat is covered.
seats	Checked seats only (pic; sic on multi-pilot aircraft). via is own (their own TR / TRI / TRE) or instructor (a TRI / TRE on board covers them); certificate is the covering certificate that stays valid longest.
uncovered	Seats that are not covered.
overridden / override_reason	A manager’s override stored on schedule_id for this crew.
can_override	The caller may proceed with a reason (user_group_id <= 110).

This endpoint is advisory

The result reports compliance; it does not decide whether an action is allowed. Nothing on this endpoint blocks a booking or a flight on its own — enforcement lives with the company settings of whichever feature is calling it:

• Self-bookings (self_schedule = 1): a non-compliant seat stops the booking only when require_pic_docs = 1 and schedule_self_allow_nodocs = 0. See Certificate gate on self-bookings.
• Manager schedule edits and flight dispatch: governed by require_pic_docs together with block_pic_without_docs.

Treat a non-compliant seat as a warning unless the relevant setting pair is active — blocking regardless would refuse bookings the API itself accepts.