Generic CSV format

What it is

The generic CSV path is the fallback import flow for any booking system other than Goboko. You upload a CSV, map the columns that carry booking data to the fields Syndik8 understands, and the wizard parses the rest.

Unlike the Goboko CSV path where columns are fixed, the generic path requires you to tell Syndik8 which column is “Start Date/Time”, which is “Member Email”, and so on.

Who can use it

Admins of a syndicate.

Where to find it

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

Fields / options

Detection

A file routes to the generic path if any of these is true:

It is not UTF-16 encoded.
It is UTF-16 but the header row is not #,Start Time,End Time,TimeZone (the Goboko signature).

Mappable fields

The column mapping step shows these Syndik8 fields next to dropdowns of the CSV’s own headers:

Field	Required?	Notes
Start Date/Time	yes	Used as booking start. Unmapped → the row is skipped.
End Date/Time	yes	Used as booking end. Unmapped → the row is skipped.
Member Name	no	Matched against the member’s name as Syndik8 displays it, and shown in the UI.
Member Email	no	Email for exact-match member lookup and invite generation. Tried before the name.
Aircraft Registration	no	For asset matching. When absent and the syndicate has a single asset, every row auto-matches that asset.
Notes	no	Copied onto the booking.
Flight Time	no	Offered in the dropdown but discarded. Nothing on the generic path reads it, so mapping it has no effect and leaving it unmapped costs nothing.

Any CSV column that is not mapped is ignored.

Supported date formats

The generic parser tries these formats in order:

Format	Example
ISO 8601 with date and time	`2026-04-25T10:00:00`
ISO 8601 with UTC marker	`2026-04-25T10:00:00Z`
ISO 8601 with UTC offset	`2026-04-25T10:00:00+01:00`
Spaced ISO	`2026-04-25 10:00:00` or `2026-04-25 10:00`
British with seconds	`25/04/2026 10:00:00`
British without seconds	`25/04/2026 10:00`

If none parses, the row is skipped.

Wizard steps for a generic import

All six steps are visible:

Upload — choose the CSV.
Columns — map each Syndik8 field to a column in your CSV, or leave it unmapped.
Members — confirm each unique member maps to an existing member, an invite, or an aircraft-maintenance entry.
Aircraft — confirm each unique aircraft registration maps to an existing asset.
Review — counts and warnings before commit.
Done — import complete.

Behaviour rules

Start and End Date/Time are required, but nothing checks that you mapped them. Next is never disabled. Leave either unmapped and the import produces no rows, and you are put back on the column-mapping step with No booking rows found after mapping — the same message a file whose dates simply will not parse gives, so it does not tell you which of the two happened. If you see it, check the two date columns are mapped before you look at the file. Every row missing either value is skipped at parse time.
Dates without an offset are treated as UTC. 2026-04-25 10:00 is read as 10:00 UTC, not 10:00 in your local time. When your source system stores local times, look for an ISO variant with a UTC offset — otherwise bookings will land an hour off during BST.
Unparseable dates skip the row. They are not saved as “pending” or pushed to the review step — they simply do not appear in the import.
Registration normalisation. The same case-insensitive, alphanumeric-only match used by the Goboko path applies here. G-QTST and GQTST are one aircraft.
Single-asset inference. If the syndicate has only one asset, every row matches that asset regardless of whether a registration column was mapped.
Member matching. Email is tried first (case-insensitive exact), then the member’s name as Syndik8 displays it (case-insensitive exact) — their nickname if they set one, otherwise their first and last name. If both fail and a row has an email, you can invite them from the matching step.
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.
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. Leave Member Email unmapped, or map a column that is blank on every row, and 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.
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.
Maintenance classification. For a generic CSV there is no auto-detection of maintenance rows. If your source system used a “Maintenance” sentinel in the member field, you can mark that entry as maintenance on the member matching step.
Re-imports are deduplicated. A row whose combination of start time, end time, member, and aircraft matches a previously imported booking in the same syndicate is skipped — see deduplication.
Goboko detection wins if it applies. Uploading a real Goboko export on this path is not possible — it will be detected as Goboko before you reach column mapping.