Accordion integration rules

The rules the IBA applies to the daily Accordion delivery of completed flights. The technical contract (authentication, payload, responses, logging) lives in Tech docs → Accordion integration.

Rules

A record is a member’s flight. It is identified by CartID and CustomerID together. A cart item shared by two members arrives as two records with the same CartID, and both are kept.
The member must exist. IBANumber must match an IBA member, or the record is rejected as unknown_member. Accordion filter non-members out before sending, so this is a safeguard rather than an expected path.
An unmapped tunnel is not a rejection. The flight happened whether or not our tunnel mapping is complete, so the record is stored with no tunnel and the gap is fixed in the mapping.
Deliveries are partial-success. Valid records in a delivery are stored even when others in the same delivery are rejected. The count per rejection reason is kept with the delivery and reported in the Monday weekly review.
Restatements win. A later record for the same CartID and CustomerID replaces the stored values; when we first heard of the flight is kept.
Absence means nothing. Deliveries do not declare a coverage period, so a booking missing from a later delivery is not treated as cancelled.

Instructors

Each record can carry Instructors, the IBA numbers of the instructors on the flight, so the auditing team can find an instructor’s flights and review the video.

Optional. A record without it is stored as before.
Not sent is not the same as none. A missing field stores nothing (NULL); an empty list [] records that the flight had no instructor.
The latest list wins. A restatement that sends Instructors replaces the stored list. One that leaves it out keeps the last list sent.
An unknown number is kept. An instructor number that matches no member never rejects the flyer’s record; it simply won’t match a member when read.

Lifecycle

Accordion send a follow-up record when a booking changes after the flight. RecordStatus is the only signal:

`RecordStatus`	Effect
`Created`	Stored
`Amended`	Stored values replaced
`Cancelled`	Marked withdrawn (`is_withdrawn = 1`), never deleted

Rows are never deleted, so anything granted against a since-cancelled booking stays explicable.

Flight times

Flights arrive on a Pacific clock with a daylight-saving-aware offset (-07:00 or -08:00, chosen by the flight date). They are stored as UTC and shown in the tunnel’s own local time. See Time zones.

Products and staff flights

Accordion’s product list (September 2026) has 176 products: download the full list (CSV). Six are staff or instructor products:

Sharecode	Product
`0STAFFMIN`	$0 Staff Flight
`5STAFFMIN`	$7 Staff Flight
`STAFFMIN`	Staff Minute
`FITP`	FITP 1 Minute Block
`FDEMO`	Flight Demo
`TRAINING`	Instructor Training

Decision (2026-09): staff flights are kept. They are stored like any other record. If they need excluding later, filter on these sharecodes where the data is read, not where it arrives, so the stored feed stays complete.

Instructor coaching products (for example “01 Min Inst Coaching”) are customer products — the member is the customer — and are not in this list.

The list’s minutes column is per unit, not per flight: 5STAFFMIN is listed as 1 minute but arrives with TotalMinutes: 5. The delivered TotalMinutes is the value to use.

Integration: Accordion — technical contract, logging and known limitations
Business logic: Integrations — the other booking-system integrations