Qargo Use case / Trip import API

Required api role: `API_TRIP`Purpose: This interface allows an external system (e.g. a route optimisation tool) to send fully planned trips into Qargo.When a trip payload arrives, Qargo creates or updates a trip with the specified stops, sequence, timestamps, and resource assignments — without manual planning.The trip import is the last step of a larger planning flow:1. The external system obtains the Qargo `id`s of the stops and resources to plan. Qargo can push this planning data to the external system (an optional export, configured per integration), or the external system fetches it via the API (e.g. orders and resources).2. The external system computes trips and assigns each one a `trip_identifier`.3. The external system pushes the planned trips to the trip import webhook.### Getting startedA trip import pushes stop sequences, resource assignments, and timing information into Qargo so that the planning board reflects the externally computed plan.The `trip_identifier` is used to determine whether an incoming trip is new or an update to an existing one:- **Create** — a new trip is created when a payload arrives with a `trip_identifier` that has not been seen before.- **Update** — if a payload arrives with a `trip_identifier` that already exists, Qargo updates the original trip rather than creating a new one.- **Cancel** — setting `status = 'CANCELLED'` will remove the trip. A trip must have been created before it can be cancelled.### Limitations- Stops must be referenced by their Qargo stop `id`. Location names, using location details or aliases are not supported.- Each stop must have a `sequence` value (starting from `0`) and a start/end timestamp. Missing either will cause the import to fail.- Resources can only be assigned by their Qargo resource `id` — not by license plate, name, or external reference.- All stops in the payload must be unplanned. Stops that are already assigned to another trip cannot be imported.- Trips are created automatically — there is no approval or review step before the trip appears on the planning board (unlike order import).- A cancelled trip cannot receive further updates. To re-import, use a new `trip_identifier`.- Stop timestamps must be logically consistent: the sequence order must match the chronological order, and a delivery stop cannot precede its corresponding pickup.- Trip import is asynchronous — the endpoint does not return trip data.- Splitting a trip into multiple trips is not supported via trip import - split the order first.- Each integration instance supports either webhook or EDI routing — not both simultaneously.