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.
Bearer-AuthAuthorizationBearer <token>id*stringThe trip's id (UUID) or your own trip_reference — either identifies the trip.
No Content — the trip and its activities were deleted.
curl -X DELETE 'https://api.sandbox.squake.earth/v2/travel-data/trips/string'Create a Purchase
You can register a purchase programmatically to compensate for carbon emissions on this endpoint. You must quote for pricing beforehand and pass the returned pricing ID as a parameter. Alternatively, you can use the `payment_link` from the pricing endpoint to finalize the purchase using SQUAKE's provided checkout page. ### Lifecycle #### When purchasing via API (this endpoint) * **reserved**: A successful purchase starts in the state "reserved"; SQUAKE registered your purchase and reserved carbon credits accordingly. * **canceled**: SQUAKE offers 14 days to cancel a purchase worry-free. This is a terminal state. * **confirmed**: The refundable period has passed. If you need to cancel the purchase beyond this point, please request a refund on the refunds endpoint. * **invoiced**: Without further action, a purchase is invoiced after the grace period and transitions to "invoiced". #### When purchasing via the checkout page * **payment_initiated**: the end customer entered the payment flow on the checkout page * **payment_aborted**: the payment failed permanently, for example, because the customer exited the page without finalizing the payment and didn''t return before the pricing''s validity ended. This is a terminal state. * **confirmed**: the payment provider informed SQUAKE about the successful payment. In this flow, this state exists only for a short time; the purchase immediately continues to "settled". #### Both * **settled**: SQUAKE has received the payment. * **refunded**: a refund request was successfully processed. This is a terminal state. * **certificates_confirmed**: all certificates for the carbon credits have been confirmed from all project partners related to the purchase. * **certificates_retired**: all certificates have been retired in the corresponding registries. This is a terminal state.
Retrieve a Travel Data Trip
Returns 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`](https://docs.squake.earth/reference/squake/travel-data/get-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`.