Learn how Skrym can help with accurate emissions estimations

Skrym is developing a range of emissions-related APIs, enabling you to supercharge your systems without losing any control of the customer journey.

This section should describe how we work with calculating emissions.

The Skrym emissions calculation endpoints are meant to help you get a complete picture of your fulfillment-related footprint on an order-level.
We calculate emissions based on two components:

Packaging emissions, calculated using the size, weight and material of the protecting package.
Shipping emissions, where we calculate the distance the order travels from warehouse to customer, using truck and terminal data to determine how much the transport emits.

We are constantly exploring new use cases together with our clients and partners, and are always open to help you find ways to use our APIs for other purposes. Please reach out to Skrym to learn more.

Emissions

Get emissions estimations for all your registered transport methods

In the logistics industry, managing and reducing greenhouse gas emissions is both a challenge and a responsibility, as the global network of shipping and transportation contributes significantly to environmental impact.
Skrym offers a sophisticated emission calculation tool designed to navigate the complexities of logistics emissions, providing businesses with reliable estimates for the carbon footprint of each order.
Skrym's emissions calculation tool leverages advanced optimization algorithms and comprehensive vehicle data to assess the environmental impact of shipping orders.
By accurately modeling delivery scenarios and considering factors such as packaging materials and accurate vehicle data, Skrym delivers granular insights into the carbon emissions associated with logistics operations.
This enables businesses to make informed decisions aimed at reducing their environmental impact and achieving sustainability goals.
How does it work?
Here is a high-level overview of the emissions calculation process:
<MermaidChart
title="Emissions Calculation Process"
subtitle="Calculation and confirmation for Emissions in a pre-payment scenario"
chart={`
sequenceDiagram
autonumber
participant C as Client
participant S as Skrym
activate C
C->>S: Call CalculateEmissionsForAllMethods
activate S
Note over S: Calculates emissions for all registered transport methods
Note over S: Calculates packaging emission for given parcel size
S-->>C: Return emissions breakdown for every configured transport method
deactivate S

Note over C: Order is confirmed
C->>S: Call ConfirmTransportForOrderEmissions
activate S
S-->>C: Confirm and finalize emissions
deactivate S
deactivate C`
}

/>

Calculate Emissions

Learn how Skrym calculates emissions for your orders

Skrym splits the emissions in E-commerce in two parts of the delivery:

Emissions from creating the packaging materials
Emissions from energy required to transport the package(s)

With Skrym, you can display estimated emissions already in the pre-payment phase, giving your customers more transparency into their choice of delivery!
Limits
Trying to do exact calculations for a shipment before it has happened is impossible due to the enormous amount of small decisions that impact the actual emissions.
Skrym utilizes the best available data to reduce any inaccuracies, but cannot guarantee that the assumptions needed to do the estimation in advanced is followed.

Methodology

Learn about the frameworks that Skrym's emission service is built on

A key aspect of how we build our product around measuring emissions is to ensure interoperability with
different frameworks. We aim to enable transparency, accountability, and comparisons by adopting a unified calculation that can be translated into different standards depending on the purpose.
To give an introduction to the three frameworks we have been working the most with, we have compiled some relevant material for
you to explore.

Frameworks

From being packed in the warehouse to being delivered to its destination, an order tends to generate emissions in several distinct points.
As outlined in the  section, there are roughly 2 main sources of emissions for an order: The Packaging and The Shipping.
The information required for us to perform the emission calculations for those sources can nevertheless be obtained at different stages of the order's life cycle. At the time of writing, we are limited to:
type CalculationOrigin string

const (
	Checkout     CalculationOrigin = "CHECKOUT"
	Booking      CalculationOrigin = "BOOKING"
	Optimization CalculationOrigin = "OPTIMIZATION"
	Tracking     CalculationOrigin = "TRACKING"
)

where not all might be available for any one order, as it depends on the retailer's permissions and the scope of our integrations. We can internally update the emission results for an order by calling:

Which will upsert into the the emission_results table in environmental first:
CREATE TABLE result_origin
(
    origin VARCHAR(255) PRIMARY KEY
);

INSERT INTO result_origin (origin)
VALUES 
    ('CHECKOUT'),
    ('BOOKING'),
    ('OPTIMIZATION'),
    ('TRACKING');

CREATE TABLE emission_results
(
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    organization_id UUID NOT NULL,
    reference_id UUID NOT NULL,
    calculated_from VARCHAR(255) NOT NULL REFERENCES result_origin(origin),
    updated_at TIMESTAMPTZ NOT NULL
);

and then proceed to upsert into the packaging_emissions and shipping_emissions tables:
CREATE TABLE packaging_emissions
(
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    emission_result_id UUID REFERENCES emission_results(id),
    package_id UUID NOT NULL,
    package_emissions FLOAT NOT NULL,
    fill_material_id UUID,
    fill_material_emissions FLOAT,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- to capture each 'step' along transportation
CREATE TABLE shipping_emissions
(
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    emission_result_id UUID REFERENCES emission_results(id),
    transport_method_id UUID NOT NULL, 
    from_location_id UUID NOT NULL,
    to_location_id UUID NOT NULL,
    tracked_shipment_id UUID,
    transported_distance FLOAT NOT NULL,
    emissions FLOAT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

The important point of this structure is the reference_id in the emission_results table. This is meant to be any one of our identifiers from the services supported in results_origin table. In other words, if the emission result has been calculated from data from BOOKING, then reference_id should be set to the booking_id in booking. If later, the same order reaches optimization (gets optimized), we may insert another entry with reference_id now set to order_core(id), and so forth.
The retrieval of a stored emission result can be done by calling the following private Getter and specifying the ReferenceID:
