Retrieve a Travel Data Trip
Changed Oct 20Returns a single stored trip, addressed either by its SQUAKE id or by your own
trip_reference. The response is the same shape the trip list returns: the identity fields a
submission echoes back plus the trip as you described it on ingestion — name, purpose, status,
dates, booking provider, amount and the nested cost_center.
The trip carries the IDs of its activities, not the activities themselves — read those from
/v2/travel-data/trips/{trip_id}/activities.
A trip you cannot access is indistinguishable from one that does not exist: both respond with
404 and error code travel_data_not_found.
Bearer-AuthAuthorizationBearer <token>id*stringThe trip's id (UUID) or your own trip_reference — either identifies the trip.
OK
application/json- response
A trip as SQUAKE stored it, returned by the trip list (GET /v2/travel-data/trips) and by a single
trip read (GET /v2/travel-data/trips/{id}): the identity fields a submission echoes back, plus
the trip as you described it on ingestion — its name, purpose, status, dates, booking provider,
amount and cost center.
This is a superset of Travel-Data-Submitted-Trip, the shape returned in the trips array of
POST /v2/travel-data. A submission reports what the request wrote; a read reports what is stored.
Fields they share mean the same thing in both, so a submission response and a later read of the
same trip never disagree.
Activities are never nested here: a trip carries only their activity_ids. Read the activities
themselves — with their calculations and audits — from
GET /v2/travel-data/trips/{trip_id}/activities.
id*stringSQUAKE's identifier for the trip. Addresses the trip on every read and delete.
uuidtrip_reference*|Your own reference for the trip, echoed from the request that created it. Also usable in place
of id in the trip paths.
client_id*stringThe client that owns the trip — the target client when the trip was submitted with a
root-level client_id, otherwise the submitting client itself.
uuidsubmitted_by_client_id*|The client whose credentials submitted the trip. null for trips that did not arrive through
POST /v2/travel-data (for example CSV imports or TMC integrations). A trip re-used by a later
submission keeps the submitter that first created it.
uuidactivity_ids*array<>The IDs of the trip's activities, in ingestion order, across all activity types. Individual
legs of a routing flight are not listed — the routed activity carries the itinerary.
A read always lists every activity of the trip, including activities added by earlier or later
submissions — unlike the activity_ids of a submission response, which covers only what that
request wrote.
trip_name*|The trip's name, echoed from ingestion. null if the source did not provide one.
trip_purpose*|The trip's purpose, echoed from ingestion. null if the source did not provide one.
trip_status*|Where the trip stands, in SQUAKE's own vocabulary. Whatever wording the source used is mapped onto these five values on ingestion and is never returned as sent.
The trip's dates decide the value wherever they can: a trip whose end_date_utc has passed
reads completed, and one already under way reads in_progress, regardless of the status the
source supplied. A cancellation outranks the dates — a trip called off after its end date
is canceled, not completed. A future trip the source considers firm reads confirmed;
anything else reads planned.
Statuses that depend on the date are re-evaluated daily, so a trip moves from confirmed to
in_progress to completed on its own.
null means the trip carries neither a status nor a date, so there is nothing to report.
"planned""confirmed""in_progress""completed""canceled"nullbooking_provider*|The provider the trip was booked through (a TMC, an online booking tool), echoed from
ingestion. null if the source did not provide one.
start_date_utc*|Start of the trip, in UTC. Ingestion accepts an ISO 8601 date (2023-10-01); it is stored and
returned as an ISO 8601 date-time (2023-10-01T00:00:00Z). Required on POST /v2/travel-data,
so only trips from other sources can report null.
date-timeend_date_utc*|End of the trip, in UTC, in the same date-time format as start_date_utc. null if the source
did not provide one.
date-timeamount_in_cents*|The booking's own amount, in the minor unit of currency (so 10000 is 100.00 USD), echoed
from ingestion. SQUAKE also derives an amount in your base currency for reporting; that one is
internal and never returned here.
currency*|3-letter ISO 4217 alpha code of amount_in_cents.
^[A-Z]{3}$cost_center*|The cost center the trip is booked against, or null for a trip that has none. The key is
always present.
Only the fields that identify the cost center to you are returned — the department and the internal id it carries in the dashboard are not part of this response.
curl -X GET 'https://api.sandbox.squake.earth/v2/travel-data/trips/string'{ "id": "0194d6b4-8711-7873-899d-c8133cd742f8", "trip_reference": "BT-2023-001", "client_id": "4fb3ec7a-92cb-471f-b75f-c3fe7c2a34d5", "submitted_by_client_id": "4fb3ec7a-92cb-471f-b75f-c3fe7c2a34d5", "activity_ids": [ "6c1f6a5e-1d0e-4b8a-9f2c-2b1e6d4a7c31", "b9a2c47d-3f61-4d0e-8f52-7c9a1e2b4d68" ], "trip_name": "Business Trip to NYC", "trip_purpose": "Client Meeting", "trip_status": "completed", "booking_provider": "Example TMC", "start_date_utc": "2023-10-01T00:00:00Z", "end_date_utc": "2023-10-05T00:00:00Z", "amount_in_cents": 10000, "currency": "USD", "cost_center": { "name": "Marketing", "purpose": "Marketing Campaign", "email": "cc@company.io" }}Delete a Travel Data Trip
Deletes a trip and everything hanging off it: all of its activities — routing legs included — and their calculations. Responds with `204` and an empty body. **Audit logs are kept.** They are an immutable record of what was calculated, so deleting a trip does not remove the audit logs its calculations produced. **Reporting lags a delete.** Dashboards and reporting views are refreshed periodically, so a deleted trip can still appear in them until the next refresh. This cannot be undone — re-submit the trip to `POST /v2/travel-data` to restore it, which recalculates its emissions and creates new IDs. A trip you cannot access responds with `404` and error code `travel_data_not_found`, and nothing is deleted.
Retrieve an Activity of a Travel Data Trip
Returns a single activity of a trip with its traveler and the calculations persisted for it. Activities are always addressed through their trip. As in the list, the key set depends on the activity `type`: `origin`/`destination` are absent for a `hotel` stay, and `fuel_type` is only returned for `car` and `train`. An activity of another trip, a routing leg, and an ID that does not exist all respond with `404` and error code `travel_data_not_found`.