Check if SQUAKE's server can be reached.
SQUAKE API Documentation
The SQUAKE Solution Suite is live with industry leaders from several travel and logistics segments and performs accurate carbon calculations for all types of activities (e.g. flights, road, accommodation amongst others) according to national and international standards. It automates carbon reductions and/or compensations along the supply chain, from supplier selection (SAF, DAC, ecological restoration) to inventory management, invoicing and credit retirement.
For any issues or inquiries, you can reach our dedicated customer support team through our Support Page. This is the best place to ask questions, report incidents, or get assistance with integrating or using SQUAKE's solutions.
Our contact forms are designed to help you communicate with us effectively. Whether you want to get in contact with our support team or need to report an incident, we've got you covered. Please use the appropriate form below:
- Contact Form: Get in contact with our customer support team or share your thoughts and suggestions about our services and processes.
- Incident Form: Report any issues or incidents you've encountered, and our support team will respond as soon as possible.
SQUAKE uses API keys to authenticate requests. You can create and revoke API keys in the Dashboard, which you can access by contacting us under product@squake.earth. You should securely store your API keys; and encrypt them on rest if possible. Be aware that each API key is shown exactly once in the UI during creation. SQUAKE advises rotating API keys on a regular basis.
To use the sandbox environment, a separate API key must be created. Switch to sandbox mode in the dashboard, then create an API key.
All requests must be authenticated and made over HTTPS. SQUAKE supports TLS 1.2 - TLS 1.3. Requests without authentication or via plain HTTP result in an error.
When using HTTP Basic Auth, the API key is the username; leave the password blank. For bearer auth, pass the API key as the token.
Example using HTTP Basic Auth (note: there is no password, but a colon is still required):
curl https://api.squake.earth/v2/pricing -u <YOUR_API_KEY>Example using bearer auth:
curl https://api.squake.earth/v2/pricing -H "Authorization: Bearer <YOUR_API_KEY>"SQUAKE associates each API request with a unique identifier. Find this value in the SQUAKE-Request-Id header. If you need to contact us regarding a specific request, providing the request identifier helps the resolution process.
Please visit status.squake.earth to check our uptime monitor. You can subscribe to events to stay informed of any service disruption. We will also publish a post-mortem about any incident should one occur.
You can programmatically check if servers are reachable. Read the documentation of the Health Check endpoints for details. The health check endpoints are the only endpoints that do not require authentication.
There is a sandbox server available for testing at
https://api.sandbox.squake.earth
Sandbox and production are separate systems and share no data. Sandbox uses less computing power and may be slower than production. Both sandbox and production environments run the same version of the API; thus, they share the same feature set.
To use the sandbox environment, a separate API key must be created. Switch to sandbox mode in the dashboard, then create an API key.
All outgoing traffic originates from one of the following static IP addresses. SQUAKE owns these IP addresses and never shares them for any other traffic.
| Environment | IP Address | Geo Region |
|---|---|---|
| Production | 52.59.66.213 | Europa/Germany |
| Production | 52.7.39.159 | USA |
| Sandbox | 18.197.251.125 | Europa/Germany |
This guide will help you make requests to the SQUAKE API in order to calculate emissions for a travel journey.
SQUAKE API has the following group of endpoints:
- Calculations - Calculates carbon emissions for various activities in a low-latency process.
- Pricing - Returns pricing for a given product and carbon quantity, valid for two weeks by default.
- Combined Calculation & Pricing - Performs carbon calculation and pricing in a single call for convenience.
- Carbon Comparison - Compares carbon quantities to recognizable items like cars or light bulbs.
- Purchases - Registers a purchase to compensate for carbon emissions, requiring a prior pricing quote.
- Products - Lists purchasable compensation options, including single climate projects and bundles.
- Files - Manages file attachments related to purchases, such as compensation confirmations.
- Webhooks - Allows you to receive notifications about events happening in SQUAKE.
- Audits - Provides a list of audits or a specific audit for calculations.
- Health Check - Verifies if SQUAKE's server is reachable.
If you want operator-specific calculations for buses, then use the following dataset supported by SQUAKE's methodology.
For road and sea logistics activities according to GLEC, use the GLEC dataset.
For operator-specific calculations for trains, use the train dataset.
For van calculations, use the EU-EEA supported dataset.
Compare carbon quantities to more recognizable items like cars or kettles. View accepted units in this comparison database.
Download OpenAPI description
Overview
Languages
Servers
Production
https://api.squake.earth/
Sandbox
https://api.sandbox.squake.earth/
Audits
Audit logs are created when enabled on calculation requests.
| ℹ️ To use this feature you need to have it enabled for your account, please contact us for more information. |
|---|
When Audit mode is enabled for a client, SQUAKE will generate audit logs if it's requested within the calculations request body. These logs are immutable; once they are created they cannot be altered—please use this feature only for final calculations.
Operational notes:
- Use audit mode whenever a calculation is for past activity / post-booking (post-validated) (e.g., ticketed & already-flown flights, completed stays/trips, historical backfills, invoice reconciliation/true-ups, corrections). These records are final and must be immutable.
- Audit mode must not be used for future-looking / pre-booking or other non-final use cases (e.g., shopping/quotes, draft or tentative itineraries, forecasting/scenario planning, preliminary estimates, or POS value requests). These are expected to change.
- Post-booking (finalized) calculations MUST be performed with audit mode enabled.
- Pre-booking (non-audit) calculated values must not be carried over into post-booking reporting; after the activity is finalized, the calculation must be re-run with audit mode enabled.
- Requests that handle points-of-sale (POS) values or other preview/estimation-only calls MUST be sent without audit mode.
Rule of thumb: Past/post-validated = audit mode; Future/pre-booking = no audit mode.
If you are calculating on behalf of a legal entity, you can create an Auditable entity via the /v2/audits/entities endpoint and use the ID from the response as the audit_for property in the calculation request. This will associate all audit logs created for that calculation with the given Auditable entity.
Operations
Travel Data
Create travel trip data and activities for reporting and analytics, and read back, or delete, what SQUAKE stored.
POST /v2/travel-data ingests trips and returns their emissions. The trip endpoints (/v2/travel-data/trips) then serve the stored records: a trip carries its own attributes and the IDs of its activities, and each activity carries its traveler and every calculation persisted for it — including the ones from additional methodologies, which the flat items array of a submission does not report.
To ingest travel data you need to have it enabled for your account — please contact us. Until then, POST /v2/travel-data and the CSV imports respond with 404 and error code travel_data_not_found. On the read endpoints that same response covers every miss: a trip that does not exist and a trip you cannot access are deliberately indistinguishable.
Operations
Request
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 — 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) 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.
Security
Bearer-Auth
Optional. Submit this travel data on behalf of a descendant client — pass the target client's id (a UUID as returned by /v2/clients). Omit it to ingest for the authenticated client (the default, unchanged behavior). Providing client_id requires this capability to be enabled for your account (contact us); an id outside your hierarchy returns client_not_found (404) and nothing is persisted. All trips in one request are owned by the same target client.
- Production
https://api.squake.earth/v2/travel-data
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X POST \
https://api.squake.earth/v2/travel-data \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
-H 'Content-Type: application/json' \
-d '{
"trips": [
{
"amount_in_cents": 10000,
"currency": "USD",
"trip_name": "Business Trip to NYC",
"trip_purpose": "Client Meeting",
"trip_reference": "BT-2023-001",
"trip_status": "completed",
"start_date_utc": "2023-10-01",
"end_date_utc": "2023-10-05",
"booking_provider": "Test Provider",
"activities": [
{
"type": "car",
"amount_in_cents": 2500,
"currency": "EUR",
"origin": "BER",
"destination": "MUC",
"fuel_type": "diesel",
"traveler": {
"name": "Mustermann",
"email": "test@company.io",
"traveler_type": "employee"
}
}
],
"cost_center": {
"name": "Marketing",
"purpose": "Marketing Campaign",
"email": "cc@company.io"
}
}
]
}'OK
SQUAKE uses The International System of Units (SI), commonly referred to as "metric system".
Enum"tonne""kilogram""gram"
The trips this request persisted, with the IDs of the activities it wrote under each one. Use these IDs to read the stored data back from the trip endpoints — including the calculations of any additional methodologies, which items does not report.
One entry per trip: two payload entries sharing a trip_reference resolve to a single trip and are reported once. activity_ids lists only the activities this request persisted, so a re-used trip holds more than the response shows.
Each entry carries the trip's identity, not the descriptive fields the request sent — reading the trip back returns those on top of these (Travel-Data-Stored-Trip).
SQUAKE's identifier for the trip. Addresses the trip on every read and delete.
Your own reference for the trip, echoed from the request that created it. Also usable in place of id in the trip paths.
The client that owns the trip — the target client when the trip was submitted with a root-level client_id, otherwise the submitting client itself.
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.
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.
In a POST /v2/travel-data response this lists the activities that request persisted; a re-used trip_reference means the trip holds more than the response shows. Read the trip to get the full list.
Response
application/json
{ "carbon_quantity": 0, "carbon_unit": "tonne", "items": [ { … } ], "trips": [ { … } ] }
Request
Returns 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.
Security
Bearer-Auth
- Production
https://api.squake.earth/v2/travel-data/trips
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data/trips
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X GET \
'https://api.squake.earth/v2/travel-data/trips?page=1&items=1' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'OK
Bodyapplication/jsonArray [
SQUAKE's identifier for the trip. Addresses the trip on every read and delete.
Your own reference for the trip, echoed from the request that created it. Also usable in place of id in the trip paths.
The client that owns the trip — the target client when the trip was submitted with a root-level client_id, otherwise the submitting client itself.
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.
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.
The trip's name, echoed from ingestion. null if the source did not provide one.
The trip's purpose, echoed from ingestion. null if the source did not provide one.
The trip's status as the source reported it, echoed from ingestion. Free-form — SQUAKE neither constrains nor normalizes the value.
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 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.
End of the trip, in UTC, in the same date-time format as start_date_utc. null if the source did not provide one.
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.
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.
Response
application/json
[ { "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": [ … ], "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": { … } } ]
Request
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.
A trip you cannot access is indistinguishable from one that does not exist: both respond with 404 and error code travel_data_not_found.
Security
Bearer-Auth
- Production
https://api.squake.earth/v2/travel-data/trips/{id}
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data/trips/{id}
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X GET \
'https://api.squake.earth/v2/travel-data/trips/{id}' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'OK
SQUAKE's identifier for the trip. Addresses the trip on every read and delete.
Your own reference for the trip, echoed from the request that created it. Also usable in place of id in the trip paths.
The client that owns the trip — the target client when the trip was submitted with a root-level client_id, otherwise the submitting client itself.
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.
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.
The trip's name, echoed from ingestion. null if the source did not provide one.
The trip's purpose, echoed from ingestion. null if the source did not provide one.
The trip's status as the source reported it, echoed from ingestion. Free-form — SQUAKE neither constrains nor normalizes the value.
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 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.
End of the trip, in UTC, in the same date-time format as start_date_utc. null if the source did not provide one.
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.
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.
Response
application/json
{ "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" } }
Request
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.
Security
Bearer-Auth
- Production
https://api.squake.earth/v2/travel-data/trips/{id}
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data/trips/{id}
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X DELETE \
'https://api.squake.earth/v2/travel-data/trips/{id}' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'Request
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.
Security
Bearer-Auth
- Production
https://api.squake.earth/v2/travel-data/trips/{trip_id}/activities
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data/trips/{trip_id}/activities
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X GET \
'https://api.squake.earth/v2/travel-data/trips/{trip_id}/activities' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'OK
The activity type of a travel data activity.
Enum"car""flight""hotel""train"
Your own reference for the activity, echoed from the request that created it.
Where the activity started, echoed from ingestion in the format it was submitted in — typically an airport code for a flight, an address, UN/LOCODE or lat/long pair for a car or train. The city and country SQUAKE resolved it to are used for the calculation and kept internally.
Only returned for flight, car and train. A hotel activity has no route, and the key is omitted rather than null.
Where the activity ended, in the same format as origin.
Only returned for flight, car and train. A hotel activity has no route, and the key is omitted rather than null.
The fuel the activity was calculated with, echoed from ingestion. The accepted values depend on the methodology — see the car and train request schemas.
Only returned for car and train. For a flight or hotel activity the key is omitted rather than null.
Who travelled, as you described them on submission, or null for an activity submitted without a traveler (common for CSV and TMC rows). The key is always present, for every activity type.
Only the fields that identify the traveler to you are returned — the department, the external employee id and the internal id the record carries in the dashboard are not part of this response.
Email of the traveler, echoed from ingestion and lower-cased. This is the value travelers are deduplicated on within a client.
The calculations persisted for this activity, oldest first — one per methodology configured for the activity type. Empty if no calculation was persisted.
The published version of that methodology for this activity type. null for methodologies that are not versioned.
Emissions of this calculation, in grams of CO₂ equivalent. Note the unit: the calculation endpoints and the items array of POST /v2/travel-data report kilograms by default.
The audit log created for this calculation, or null when the activity was submitted without audit mode. Only the id is returned — read the full log from /v2/audits/{id}.
Response
application/json
[ { "id": "6c1f6a5e-1d0e-4b8a-9f2c-2b1e6d4a7c31", "type": "flight", "trip_id": "0194d6b4-8711-7873-899d-c8133cd742f8", "client_id": "4fb3ec7a-92cb-471f-b75f-c3fe7c2a34d5", "external_reference": "ACTIVITY-FLIGHT-OUTBOUND", "origin": "BER", "destination": "LHR", "traveler": { … }, "calculations": [ … ] } ]
Request
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.
Security
Bearer-Auth
- Production
https://api.squake.earth/v2/travel-data/trips/{trip_id}/activities/{activity_id}
- Sandbox
https://api.sandbox.squake.earth/v2/travel-data/trips/{trip_id}/activities/{activity_id}
- curl
- Payload
- JavaScript
- Ruby
- Node.js
- Java
- C#
- PHP
- Python
- Go
- R
curl -i -X GET \
'https://api.squake.earth/v2/travel-data/trips/{trip_id}/activities/{activity_id}' \
-H 'Authorization: Bearer <YOUR_TOKEN_HERE>'OK
The activity type of a travel data activity.
Enum"car""flight""hotel""train"
Your own reference for the activity, echoed from the request that created it.
Where the activity started, echoed from ingestion in the format it was submitted in — typically an airport code for a flight, an address, UN/LOCODE or lat/long pair for a car or train. The city and country SQUAKE resolved it to are used for the calculation and kept internally.
Only returned for flight, car and train. A hotel activity has no route, and the key is omitted rather than null.
Where the activity ended, in the same format as origin.
Only returned for flight, car and train. A hotel activity has no route, and the key is omitted rather than null.
The fuel the activity was calculated with, echoed from ingestion. The accepted values depend on the methodology — see the car and train request schemas.
Only returned for car and train. For a flight or hotel activity the key is omitted rather than null.
Who travelled, as you described them on submission, or null for an activity submitted without a traveler (common for CSV and TMC rows). The key is always present, for every activity type.
Only the fields that identify the traveler to you are returned — the department, the external employee id and the internal id the record carries in the dashboard are not part of this response.
Email of the traveler, echoed from ingestion and lower-cased. This is the value travelers are deduplicated on within a client.
The calculations persisted for this activity, oldest first — one per methodology configured for the activity type. Empty if no calculation was persisted.
The published version of that methodology for this activity type. null for methodologies that are not versioned.
Emissions of this calculation, in grams of CO₂ equivalent. Note the unit: the calculation endpoints and the items array of POST /v2/travel-data report kilograms by default.
The audit log created for this calculation, or null when the activity was submitted without audit mode. Only the id is returned — read the full log from /v2/audits/{id}.
Response
application/json
{ "id": "6c1f6a5e-1d0e-4b8a-9f2c-2b1e6d4a7c31", "type": "flight", "trip_id": "0194d6b4-8711-7873-899d-c8133cd742f8", "client_id": "4fb3ec7a-92cb-471f-b75f-c3fe7c2a34d5", "external_reference": "ACTIVITY-FLIGHT-OUTBOUND", "origin": "BER", "destination": "LHR", "traveler": { "name": "Jane Doe", "email": "jane.doe@example.com", "traveler_type": "employee" }, "calculations": [ { … } ] }
Clients
Manage a hierarchy of clients and submit travel data on their behalf. One authenticated integration can create child clients and act for any of its descendants — no separate credential per child.
To use these endpoints you need to have this feature enabled for your account — please contact us. Until then, every /v2/clients endpoint responds with 404.
Environment isolation: sandbox and production hierarchies are entirely separate. Clients created in sandbox exist only in sandbox, ids and external_references have no parity across environments, and there is no sync in either direction (the same test/live model you may know from other providers).
Operations