List Travel Data Trips
Changed Oct 20Returns the trips stored for the authenticated client, most recently ingested first. Trips from every source are listed — API submissions, CSV imports and TMC integrations alike.
Each trip is returned in full: the identity fields a submission echoes back (id,
trip_reference, client_id, submitted_by_client_id, activity_ids) plus the trip as you
described it on ingestion — trip_name, trip_purpose, trip_status, start_date_utc,
end_date_utc, booking_provider, amount_in_cents, currency and the nested cost_center.
What a trip does not carry is its activities: only their IDs. Read an activity, its
traveler, its calculations and its audit references from
/v2/travel-data/trips/{trip_id}/activities.
Pagination: results are paginated with the page and items query parameters, and the
pagination metadata is returned in the response headers (Current-Page, Page-Items,
Total-Pages, Total-Count, and an RFC 8288 Link header).
Multi-client: if submitting on behalf of other clients is enabled for your account, this lists the trips of the authenticated client and all of its descendants. Otherwise only your own trips are returned — never a parent's, a sibling's, or an unrelated client's. A client with no stored trips gets an empty array.
Bearer-AuthAuthorizationBearer <token>page?numberPage number for pagination (starts at 1).
1 <= valueitems?numberNumber of trips per page. Defaults to 20, capped at 100.
1 <= value <= 100OK
application/json- response
[index: integer]?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.
curl -X GET 'https://api.sandbox.squake.earth/v2/travel-data/trips'[ { "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" } }]List the Activities of a Travel Data Trip
Returns every activity of a trip, in ingestion order, each with its traveler and the calculations persisted for it. A trip is a single booking, so the list is bounded and returned in full — it is not paginated. This is where additional methodologies become visible: the `items` array of `POST /v2/travel-data` only reports the primary methodology of each activity, while an activity here carries one calculation per methodology configured for its type. **The key set varies by activity `type`.** `origin` and `destination` are returned for `flight`, `car` and `train` but not for `hotel`; `fuel_type` only for `car` and `train`. A key the type cannot have is omitted rather than returned as `null`, so read `type` first. `traveler` is always present, and is `null` for an activity submitted without one. Individual legs of a `routing` flight are not listed — the routed activity carries the itinerary total. A trip you cannot access responds with `404` and error code `travel_data_not_found`.
Create Travel Data Items
Accepts trip records with nested activities for travel data ingestion. **Request size limit:** A single request may contain a maximum of **50 activities** in total across all trips. For larger data sets, split your payload into batches of up to 50 activities and send each batch as a separate request. Requests exceeding this limit are rejected with a `400` error before any data is persisted. If an activity omits `methodology`, SQUAKE selects the client's configured default methodology for that activity type. Pass `methodology` only when you want to override that default for a specific activity. **Supported activity types:** `car`, `flight`, `hotel`, and `train`. **Monetary values:** Both trips and individual activities accept `amount_in_cents` and `currency`. Use activity-level values to attribute spend to a specific leg; they take precedence over trip-level values in activity-based reporting. When `currency` is present, `amount_in_cents` must be a positive integer. The API does not accept `amount_base_currency`. **Reading the data back:** alongside the flat `items` array, the response returns a `trips` array with the ID of every trip this request persisted and the IDs of the activities written under it. Store those IDs to read, or delete, the stored records later via [`/v2/travel-data/trips`](https://docs.squake.earth/reference/squake/travel-data/get-v2-travel-data-trips) — or address a trip by your own `trip_reference` instead. A `trips` entry reports the trip's identity only; a trip read returns those same fields plus the trip as you described it (name, purpose, status, dates, booking provider, amount, cost center). **On behalf of another client:** pass an optional root-level `client_id` (a client `id` as returned by [`/v2/clients`](https://docs.squake.earth/reference/squake/clients/get-v2-clients)) to store this travel data under a descendant client. Submitting data for another client must be enabled for your account (contact us); omitting `client_id` preserves the existing behavior of ingesting for the authenticated client. Note that CSV imports (`/v2/travel-data/imports`) do not accept `client_id`. **Flight routing:** `flight` activities accept the same methodology-specific fields as the corresponding `/v2/calculations` flight schemas, including `routing` for multi-leg itineraries (a hyphen-separated airport chain, e.g. `BER-FRA-JFK`) as an alternative to `origin`/`destination`. Exactly one of `routing` or the `origin`/`destination` pair must be provided; `routing` only applies to `flight` activities.