Home/Offers/Logistics & Supply Chain/Carbon Emissions Calculation API

Logistics & Supply Chain

Carbon Emissions Calculation API

Every customer now asks for the emissions figure for their shipment. Very few of the figures being supplied would survive being asked how they were calculated.

Freight forwarders
Shippers with reporting obligations
Carriers
Supply chain software vendors
Sustainability reporting platforms

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

Emissions reporting arrived in logistics as a customer requirement before it arrived as a capability. A shipper asks its forwarder for the carbon figure on a lane, the forwarder produces a number from a spreadsheet of default factors, and the number goes into a sustainability report without anyone being able to say what data it rests on. When the report is assured, or a customer's auditor asks, the method cannot be reconstructed.

The numbers are also more variable than people expect. The same container on the same route can differ by a large factor depending on the vessel, its utilisation, the fuel burned, whether the figure covers combustion only or includes fuel production, and whether empty repositioning is allocated to it. Two defensible calculations of the same shipment can disagree substantially, which is exactly why the method has to travel with the figure.

The honest distinction at the centre of this build is between estimated and measured. Almost all freight emissions reporting is modelled from distance, mode, weight and default intensity factors. That is legitimate and it is what the standards contemplate, but it is not a measurement. Primary data — actual fuel consumed, actual vehicle and utilisation — produces a different and better figure, and a product that presents both as the same thing is setting its users up for an awkward conversation with an assurer.

Who buys this

Freight forwarders, Shippers with reporting obligations, Carriers, Supply chain software vendors, Sustainability reporting platforms

Category: Logistics & Supply Chain

What the API returns

What comes back

Emissions per shipment and per leg, with well-to-wheel and tank-to-wheel reported separately
Data quality rating per calculation, from primary fuel data to default factors
Method and factor provenance attached to every figure
Mode-specific calculation for road, rail, sea, air and inland waterway
Allocation basis stated explicitly, including empty running and utilisation assumptions
Route and lane level aggregation for reporting periods
Scope mapping showing which reporting category a figure belongs to
A clear statement of which reporting standards a given figure can support

Endpoints

Method	Path	Returns
POST	/v1/emissions/shipment	Emissions for one shipment across its legs
POST	/v1/emissions/batch	Emissions across a batch of shipments
POST	/v1/emissions/lane	Lane-level intensity for planning and tendering
GET	/v1/factors	Emission factors in use with source and vintage
POST	/v1/primary-data	Submit actual fuel or utilisation data to upgrade a calculation
GET	/v1/reports/{period}	Aggregated figures for a reporting period with method notes

Request and response

illustrative

Request

{
  "shipment_ref": "SHP-2026-10-4471",
  "legs": [
    { "mode": "sea_container", "origin": "VNSGN", "destination": "NLRTM",
      "teu": 1, "cargo_weight_t": 18.2 },
    { "mode": "road_ftl", "origin": "NLRTM", "destination": "GB_M1",
      "vehicle": "articulated_hgv", "cargo_weight_t": 18.2,
      "primary_fuel_litres": 412.0 }
  ],
  "boundary": "well_to_wheel",
  "standard": "glec_v3"
}

Response

{
  "shipment_ref": "SHP-2026-10-4471",
  "total_co2e_kg": 1842.4,
  "boundary": "well_to_wheel",
  "standard_alignment": "glec_v3",
  "legs": [
    {
      "mode": "sea_container",
      "distance_km": 16420,
      "co2e_kg": 1498.1,
      "tank_to_wheel_kg": 1261.0,
      "well_to_tank_kg": 237.1,
      "data_quality": "modelled_default",
      "method": {
        "factor": "glec_sea_container_default",
        "factor_vintage": "2025",
        "utilisation_assumed": 0.70,
        "empty_repositioning": "included_in_factor"
      }
    },
    {
      "mode": "road_ftl",
      "distance_km": 612,
      "co2e_kg": 344.3,
      "data_quality": "primary_fuel_data",
      "method": {
        "basis": "actual_fuel_consumed",
        "fuel_litres": 412.0,
        "fuel_type": "diesel_b7",
        "allocation": "cargo_weight_share"
      }
    }
  ],
  "reporting": {
    "supports": ["glec_v3_aligned_reporting", "ghg_protocol_scope_3_category_4"],
    "does_not_support": ["verified_measured_emissions_claim"],
    "caveat": "Sea leg is modelled from default intensity factors, not measured."
  }
}

Where the data comes from

Published emission factor databases	Recognised factor sets with documented vintage and scope, which is what makes a figure defensible rather than invented
Your shipment and transport records	Modes, legs, weights, distances and equipment — the inputs, and usually the limiting factor on accuracy
Carrier primary data	Actual fuel consumption and utilisation where a carrier will supply it, which upgrades a leg from modelled to primary
Telematics and fuel records	For your own fleet, actual consumption per journey, which is the best available basis
Vessel and aircraft reference data	Vessel class, aircraft type and route data, which materially change intensity for sea and air legs
Distance and routing data	Actual routed distance rather than great-circle, since the difference is large on road and sea legs

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Calculation to a recognised methodology with the standard named in the response, rather than a house method presented as authoritative
Data quality rating per leg on an explicit hierarchy, from primary fuel data down to default factors
Well-to-tank and tank-to-wheel components reported separately, because the standards and the questions differ
Allocation assumptions — utilisation, empty running, cargo weight share — stated in the response instead of buried in the factor
Factor vintage tracking, since figures computed on a 2023 factor set are not comparable with a 2026 set and restatements matter
Primary data upgrade path, so a leg moves from modelled to primary when a carrier supplies actual consumption, with the change auditable
Validation against carrier-reported figures where both exist, with divergence reported rather than reconciled silently
Recalculation history retained, because an assured report needs the figure as it stood at the time it was published

What it changes for the business

Figures that survive scrutiny

Method and data quality attached to every number means an assurer or customer auditor gets an answer.

A defensible customer response

Forwarders can answer shipment-level emissions requests without assembling a spreadsheet each time.

Mode and lane comparison

Intensity at lane level supports procurement and modal shift decisions on a consistent basis.

A clear improvement path

Data quality ratings show exactly which legs would benefit from primary carrier data.

How it fits into your product

How it embeds

Shipment data posted from your TMS, with batch endpoints for a reporting period
Primary fuel and utilisation data submitted separately to upgrade specific legs
Factor set and vintage pinned per reporting period so a published figure can be reproduced
Reporting endpoints that aggregate to the categories your reporting framework expects
Emissions figures returned alongside the method block, so your UI cannot display a number without its basis
Deployment inside your infrastructure where shipment data is commercially sensitive

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 12 weeks

Discovery and data review

Weeks 1–2

We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.

Architecture and prototype

Weeks 3–4

You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.

Production build

Weeks 5–10

Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.

Integration and handover

Weeks 11–12

We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Is this a measurement of our emissions?

For most legs, no — it is a modelled estimate, and the response says so. Modelled figures from recognised default factors are what the freight standards contemplate and they are legitimate for reporting, but they are not measurements. Only legs where actual fuel consumption is supplied are calculated from primary data, and those are labelled differently. Presenting a modelled figure as a measured one is the mistake this build is designed to prevent.

Which reporting standards can these figures support?

The response states it per calculation. Figures aligned to a recognised freight methodology support that methodology's reporting and the corresponding value-chain category under general greenhouse gas accounting. They do not support a claim of verified measured emissions, and they are not a substitute for an assurance engagement. Where a specific framework needs inputs we do not have, the API says what is missing rather than producing a figure anyway.

Why do your numbers differ from our carrier's?

Usually because of allocation and boundary choices rather than arithmetic — utilisation assumptions, whether empty repositioning is included, whether the figure covers fuel production as well as combustion. Where both figures exist the API reports the divergence and the differing assumptions instead of quietly adopting one. Reconciling them is a conversation with the carrier, and having the assumptions written down is what makes that conversation possible.

Can we use this for offsetting or for customer-facing carbon claims?

Be careful. Modelled estimates with stated uncertainty are reasonable for internal reporting and for answering customer data requests. Marketing claims about carbon neutrality are subject to regulatory scrutiny in several jurisdictions and generally demand a higher evidentiary standard than a default-factor calculation provides. We would supply the figures and the method; the claim is your legal team's decision, and we would advise them to see the data quality ratings first.

What happens when the factor sets are updated?

Figures are pinned to the factor vintage used, and recalculation under a newer set is an explicit operation that produces a restated figure alongside the original. Silently updating historical figures breaks comparability and causes real problems when a prior-year report has already been published.

All Logistics & Supply Chain offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers