These guides cover pushing data into Ketendo from an external system, and reading back the reference lists you need to do it. Every endpoint is an upsert keyed on your identifier, so the same call is safe to retry.
Guides
Platform
Authentication, the conventions every endpoint follows, the batch endpoint, members and reconciliation. Read this first, whichever module you are integrating.
Transportation
Trains, coaches and compartments, routes and journeys, passengers, bookings and crew, plus the transport lookups they depend on.
Workforce
Employees and the reference data attached to them. The reference lists are documented today; employee records are not yet exposed to integrations.
New here?
- Get a Bearer token for the environment you are calling. Tokens expire after about 15 minutes, so a long load has to refresh partway through.
- Agree a fixed source system name for the
X-Source-Systemheader, for exampleFABRIC. It is how Ketendo tracks which records came from you. - Decide your ExternalId scheme. It is your own key for a record, and sending the same one again updates rather than duplicates. Never reuse one for two real-world records.
- Send CompanyId on every call. It is required and is never inferred.
Those four apply to every module. Platform covers them
in full, along with the batch endpoint and reconciliation.
Two ways to send data
| Way | Endpoint | Best for | Records per call |
|---|---|---|---|
| Single record | /v1/integration/<module>/Save… |
Adding or updating one thing at a time, and while you are still testing | 1 |
| Batch | /v1/integration/sync/batch |
Bulk loads. Operations can span modules and declare dependencies on each other, and one bad record does not stop the rest | Many (100 per call is a good starting size) |