Goboko CSV format

What it is

The Goboko CSV path is a specialised import flow for bookings exported from Goboko. When you upload a file, Syndik8 looks at the file’s bytes to decide whether it is a Goboko export or an arbitrary CSV — and if it is Goboko, the column mapping step is skipped entirely.

Goboko exports are UTF-16 encoded and have a fixed 16-column header. Both facts are used to detect the format automatically. You never choose “Goboko” from a menu; you upload the file you got from Goboko and Syndik8 recognises it.

Who can use it

Admins of a syndicate. The import wizard is hidden from regular members.

Where to find it

Syndicate settings → Import bookings.
Route: /syndicates/:syndicateId/settings/import-bookings.

Fields / options

Detection

Check	Expected value
Byte-order mark	UTF-16LE (`FF FE`) or UTF-16BE (`FE FF`) at the start of the file.
Header row	Starts with `#,Start Time,End Time,TimeZone`.

A file that does not meet both of those is classified as a generic CSV instead.

Columns read by the importer

The importer reads a subset of Goboko’s 16 columns:

Column index	Column name	What Syndik8 uses it for
1	Start Time	Booking start (`dd/MM/yyyy HH:mm:ss` in the row’s timezone).
2	End Time	Booking end (same format).
3	TimeZone	IANA timezone name, used to convert the start/end times to UTC.
4	Booking Made For	Matched against the member’s name as Syndik8 displays it. Also the maintenance marker — see below.
5	Booked By (email)	Member email for matching. Tried before the name.
6	Aircraft	Aircraft registration.
8	Provisional	`Y` if the row is a waitlist / provisional booking. Mapped to `pending` on import.
10	Flight Time	Hours flown (kept as metadata; not used to populate usage logs).
15	Notes	Free-text notes. Copied onto the booking.

Columns 0, 7, 9, 11, 12, 13, 14 are read past but not used.

Wizard steps for a Goboko import

The wizard has six numbered steps across the top. For a detected Goboko file:

Upload — choose the file.
Columns — skipped automatically. Goboko’s columns are known.
Members — confirm each unique member in the CSV maps to an existing syndicate member, an invite to send, or an aircraft-maintenance entry.
Aircraft — confirm each unique aircraft registration in the CSV maps to an existing asset.
Review — see the counts (created / skipped / warnings) before committing.
Done — the import completes and the bookings appear on the calendar.

Behaviour rules

Detection is on the file, not on a menu choice. There is no “Is this a Goboko export?” toggle.
UTF-16 decoding is mandatory. If Goboko ever ships a UTF-8 export, Syndik8 will route the file through the generic CSV path instead — the detection check requires the UTF-16 BOM.
Times are converted to UTC. Each row carries its own timezone; Syndik8 converts dd/MM/yyyy HH:mm:ss in that timezone to UTC before saving.
Unknown timezones fall back to UTC. If the timezone column holds a name the system’s tz database does not recognise, the time is saved as if the timestamp were already UTC rather than rejecting the row.
Maintenance convention. A row whose “Booking Made For” is Maintenance (case-insensitive) with no email is auto-classified as an aircraft maintenance booking, not a member’s booking. On the member matching step it is surfaced with the label “Will be imported as aircraft maintenance” and you can revert it to a member assignment if the detection was wrong.
Custom maintenance labels are preserved. If a Goboko row says “50 hr check” with no email, you can mark it as maintenance on the member matching step — the label “50 hr check” is carried onto the booking’s maintenance description. The generic word “Maintenance” is treated as redundant and left blank.
Member matching. The row’s email is tried first (case-insensitive exact), then “Booking Made For” against the member’s name as Syndik8 displays it — their nickname if they set one, otherwise their first and last name. Goboko’s names often differ from the ones people registered with, which is why email is tried first.
Members are matched by their real email, which only admins can see. Nobody’s email address is stored on anyone else’s phone, so the wizard asks the server for the syndicate’s addresses while you are on the matching step, uses them, and keeps nothing. Only an admin of that syndicate can make that request. If it cannot be made — you are offline, for instance — the matching step says so and falls back to matching on names alone.
Addresses are only requested when your file has one. If the Email column is blank on every row, the wizard never asks for the syndicate’s addresses at all: there would be nothing to compare them against, and matching would come down to names either way. It is not treated as a failed lookup, so the matching step does not warn you about it.
A name shared by two members is never guessed. If two people in the syndicate display the same name, a CSV row carrying that name is left unmatched for you to resolve from the dropdown rather than assigned to whichever was found first.
Every imported booking belongs to a member. A row Syndik8 cannot tie to one is skipped and counted on the review step, which also lists the row numbers. Nothing is imported to be reassigned later.
Pending invitees are not matched, and their rows are skipped. Someone who has been invited but has not yet joined has no account to own a booking. Invite them from the matching step, and once they have joined import the same file again — deduplication skips everything already created, so only their bookings are added.
Provisional rows are saved as pending. Confirmed rows land as confirmed.
Registration normalisation. G-QBBN and GQBBN in the CSV are treated as the same aircraft when matching against asset registrations (Syndik8 strips non-alphanumeric characters and compares case-insensitively).
Single-asset inference. If the syndicate has only one asset, all rows match that asset regardless of the CSV’s registration column.
A short row is dropped without comment. Goboko’s export has 16 columns; a row carrying fewer is skipped silently, with no warning and no entry in the review counts. If the created count is lower than the rows in your file and nothing explains the difference, open the CSV and look for truncated lines.
Re-running an import is safe. Fingerprint-based deduplication skips rows already imported.