Technical Specifications for PCF Data Exchange (Version 3.0.0)

1. Introduction

This document contains the necessary technical foundation for the PACT Network, an open and global network for emission data exchange.

The goal of this document is to enable the interoperable exchange of Product Carbon Footprints across conforming host systems.

The methodological foundation of the specification is the PACT Methodology Version 3.0, see [PACT-METHODOLOGY].

For an overview of changes since the last version (2.3), see the Appendix A: Changelog.

1.1. Status of This Document

Comments regarding this document are welcome. Please file issues directly on GitHub, or send them to pact@wbcsd.org.

This document was published by Partnership for Carbon Transparency (PACT) after an update to the PACT Methodology was made.

The technical specifications within this document are the result of consensus processes by PACT members and the WBCSD.

PACT recommends the wide deployment of this specification.

1.2. Scope

The scope of this document is to reach interoperability for product-level GHG emission data exchange through the definition of a data model (§ 4 Data Model) based on the PACT Methodology Version 3.0 and the definition of a HTTP REST API (§ 5 HTTP REST API).

1.3. Intended Audience

This technical specification is for

• software developers who want to build software for the exchange of product footprints according to the PACT Methodology;

• auditors and sustainability experts who want to understand the data semantics of product footprints or how they are exchanged between partners; and

• anyone that wants to understand more about the technological foundations of the PACT Network.

1.4. About PACT and the PACT Network

The PACT (previously Pathfinder) Network is a concept developed by PACT and powered by the World Business Council for Sustainable Development (WBCSD). PACT is working toward the vision of an open and global network of interoperable solutions for the secure peer-to-peer exchange of accurate, primary and verified product emissions data – across all industries and value chains.

For further information, please refer to the PACT website and the PACT Pathfinder Network Vision Paper.

1.5. Disclaimer

While PACT encourages the implementation of the technical specifications by all entities to start creating a harmonized system, neither PACT, WBCSD, nor any other individuals who contributed to the development of this document assume responsibility for any consequences or damages resulting directly or indirectly from the use of this document.

1.6. Acknowledgements

WBCSD would like to thank all PACT members, WBCSD staff, and others who shared their detailed and thoughtful input and contributed actively to the development of this document.

PACT would also like to expressly thank the 40+ solutions which implemented V2 of the PACT Technical Specifications and became conformant during 2023 and 2024, resulting in significant learnings and feedback which is now incorporated in V3.

1.7. License

Refer to the LICENSE for use of this document.

2. Terminology

Data Model Extension

A data model extension is a set of definitions that extends the data model of this document.

The encoding of a data model extension in the data model is specified in § 4.8 DataModelExtension

See [DATA-MODEL-EXTENSIONS] and [EXTENSIONS-GUIDANCE] for further details.

Data recipient

The company requesting and/or receiving PCF data from another company, using the technical means specified in this document.

Data owner

The company exchanging PCF data with another company, using the technical means specified in this document.

interoperable

The quality of being able to exchange data between host systems irrespective of the vendors of the host systems, without the need for translation or transformation of the data.

Greenhouse Gas (emissions) (GHG)

Gaseous constituents of the atmosphere, both natural and anthropogenic, that absorb and emit radiation at specific wavelengths within the spectrum of infrared radiation emitted by the Earth’s surface, its atmosphere and clouds. GHGs include CDCO₂, Methane (CH4), Nitrous Oxide(N₂O), Hydrofluoro-Carbons (HFCs), Perfluorocarbons (PFCs) and Sulfur Hexafluoride (SF6).

OpenId Provider Configuration Document

A OpenId Provider Configuration Document document provided in accordance with [OPENID-CONNECT] Section 4

Partnership for Carbon Transparency (PACT)

A WBCSD-led group of companies and organizations working together to develop a global and open network for the secure peer-to-peer exchange of accurate, primary and verified product emissions data. See www.carbon-transparency.org for more information.

PACT Methodology Version 3.0 (PACT Methodology)

Guidance for the Accounting and Exchange of Product Life Cycle Emissions, building on existing standards and protocols, such as the GHG Protocol Product standard. Previously named PACT Framework. See [PACT-METHODOLOGY] for further details.

PACT Network

An information network (previously Pathfinder Network) of and for companies to securely exchange environmental data with each other, with an initial focus on PCF data.

Product Carbon Footprint (PCF)

The carbon (equivalent) emissions relating to a product. Products can be any kind of item exchanged between entities, including metric or volumetric quantities of a product. The ProductFootprint data model is a digital representation of a PCF in accordance with the PACT Methodology.

Solution Provider

An entity providing technical solutions to companies by implementing and offering host systems.

Solution

Any PACT-conformant software host system is called a solution.

UN geographic region, UN geographic subregion

See https://unstats.un.org/unsd/methodology/m49/ for details.

3. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, SHALL, SHALL NOT, OPTIONAL, RECOMMENDED, REQUIRED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

A conforming host system is any algorithm realized as software and/or hardware that complies with the relevant normative statements in § 5 HTTP REST API.

A conforming requesting data recipient is any algorithm realized as software and/or hardware that complies with the relevant normative statements in § 5 HTTP REST API.

4. Data Model

4.1. Introduction

This section specifies a data model for product footprints conforming with the PACT Methodology Version 3.

The overall data model is designed for interactions between data owners and data recipients, to enable (i) interoperability, (ii) comparability of and transparency over product footprints, or (iii) the calculation of derived CarbonFootprints from other CarbonFootprints.

The data model consists of the following major data types:

1. ProductFootprint: contains information to identify a product, plus further information such as the CarbonFootprint

2. CarbonFootprint: contains information related to the carbon footprint of a product.

3. DataModelExtension: contains additional information beyond the data model specified in this document.

Additional uses of the data model are supported through the concept of Data Model Extensions. These allow data owners to add further information to a ProductFootprint.

4.2. Validation

This specification defines two distinct validation layers that serve different purposes:

1. OpenAPI Schema Definition - The schema definition for the data model API specifies the technical requirements for machine-to-machine communication and exchange of PCFs. Software implementations MUST adhere to these requirements for interoperability.

2. PACT Methodology Reporting Rules - A set of rules that state what data to include to properly follow carbon reporting practices. These rules indicate which properties are expected to be filled in according to the PACT Methodology.

A conformant software implementation MUST adhere to the OpenAPI schema for all API methods and data objects.

Additionally, implementations CAN incorporate functionality to assist end-users with following the PACT Methodology reporting rules, such as by validating inputs or signaling missing information. This logic should be implemented in the user interface of the application, while inter-machine communication is governed solely by the OpenAPI schema.

4.3. OpenAPI Schema

The data model and API actions described here are formally defined in the [OpenAPI] specification available at https://docs.carbon-transparency.org/.

The OpenAPI schema serves two critical functions:

1. It defines the complete structure of the PACT data model, including all data types, properties, and their relationships.

2. It specifies the technical requirements for API compliance, including:

• The minimum set of properties that MUST be provided for valid API communication

• Required data formats and value constraints

• Valid request and response structures for each API endpoint

Implementations MUST conform to this schema to ensure interoperability when exchanging product footprints through the REST API. The schema should be considered the authoritative technical reference for all implementation decisions related to data structure and API communication.

4.3.1. Basic Types

The following basic types are used in the data model:

"Sample string"

"{91715e5e-fd0b-4d1c-8fab-76290c46e6ed}"

"urn:gtin:5695872369587"

"12.3456",
"-9876.5432102"
"1.2345e+6"

123,
-456

"2025-04-23T18:25:43.511Z"
"2025-04-24T12:13:44Z"

true

4.3.2. Qualifiers

Types can have the following qualifiers. Any data object send to or from the API MUST to adhere to these for interoperability between host systems.

4.4. PACT Methodology Reporting Rules

In addition to the technical requirements defined in the OpenAPI schema, the PACT Methodology defines a set of reporting expectations for carbon footprint data.

These rules indicate which properties SHALL, SHOULD or MAY be provided in specific reporting contexts, even if they are technically optional in the API schema. These reporting rules are expressed using the following notation:

Where applicable, the specification below also includes information on the unit of certain properties (e.g. kgCO2e: kilogram CO2 equivalent) and if values are expected to be negative or positive.

See PACT Methodology for more details.

4.5. Undefined Properties

In a JSON object, a property is deemed undefined if it is either not present in the object or explicitly set to null. For example:

{
  "property1": "value1",
  "property2": null
}

In this example, property2 is considered undefined. Also, any property not present in the object, for example property3 is also considered undefined.

4.6. ProductFootprint

The objective of a ProductFootprint is to provide interoperability between the creator (the data owner) and the consumer (the data recipient) of ProductFootprints. The details on the exchange of ProductFootprints are specified in § 5 HTTP REST API.

Conceptually, the data type ProductFootprint is modeled as a multi-purpose container for product-specific emission factors which is supported by extensibility through Data Model Extensions.

Data Model Extensions enable data owners to exchange additional information related to a product with data recipients. The details are specified in § 4.8 DataModelExtension as well as [EXTENSIONS-GUIDANCE], and [DATA-MODEL-EXTENSIONS].

Each ProductFootprint can and should be updated over time, for instance to incorporate new or refined data from data owners (see § 7 Product Footprint Lifecycle).

4.6.1. Properties

"id": "f4b1225a-bd44-4c8e-861d-079e4e1dfd69"

"specVersion": "3.0.0"

"precedingPfIds": [
  "f4b1225a-bd44-4c8e-861d-079e4e1dfd69",
  "079e425a-464f-528d-341d-4a944a1dfd70"
]

"created": "2024-10-31T00:00:00Z"

"status": "Active"

"companyIds": [
  "urn:company:example:company1"
]

"productClassifications": [
  "urn:pact:productclassification:un-cpc:1234"
]

4.7. CarbonFootprint

4.7.1. Scope of a CarbonFootprint

Each CarbonFootprint is scoped by

1. Time Period: the time period is defined by the properties referencePeriodStart and referencePeriodEnd (see PACT Methodology section 3.2.3)

2. Geography: further set by the properties geographyRegionOrSubregion, geographyCountry, and geographyCountrySubdivision (see PACT Methodology section 3.2.3)

If a CarbonFootprint

1. Has geographical granularity Global, then the properties geographyCountry and geographyRegionOrSubregion and geographyCountrySubdivision MUST be undefined;

2. Has a regional or sub-regional geographical granularity, then the property geographyRegionOrSubregion MUST be defined and the properties geographyCountry and geographyCountrySubdivision MUST be undefined;

3. Has a country-specific geographical granularity, then property geographyCountry MUST be defined AND the properties geographyRegionOrSubregion and geographyCountrySubdivision MUST be undefined;

4. Has a country subdivision-specific geographical granularity, then property geographyCountrySubdivision MUST be defined AND the properties geographyRegionOrSubregion and geographyCountry MUST be undefined.

4.7.2. Properties

"geographyRegionOrSubregion": "Eastern Asia"

"geographyCountry": "US"

"geographyCountrySubdivision": "US-CA"

"ipccCharacterizationFactors": [
  "AR6"
]

"crossSectoralStandards": [
  "ISO14067",
  "PACT-3.0"
]

"productOrSectorSpecificRules": [
  {
    "operator": "PEF",
    "ruleNames": [
      "PEF 1.0",
      "PEF 2.0"
    ]
  },
  {
    "operator": "PCR",
    "ruleNames": [
      "PCR-A"
    ]
  }
]

"exemptedEmissionsPercent": "5.3"

"secondaryEmissionFactorSources": [
  {
    "name": "ecoinvent",
    "version": "3.7"
  }
]

4.8. DataModelExtension

See [DATA-MODEL-EXTENSIONS] for technical details and [EXTENSIONS-GUIDANCE] for data model extension guidance.

{
  "specVersion": "2.0.0",
  "dataSchema": "https://reg.carbon-transparency.org/shipment/1.0.0/data-model.json",
  "data": {
    "shipmentId": "S1234567890",
    "consignmentId": "Cabc.def-ghi",
    "shipmentType": "PICKUP",
    "weight": 10,
    "transportChainElementId": "ABCDEFGHI"
  }
}

4.8.1. Properties

4.9. ProductOrSectorSpecificRule

{
  "operator": "PEF",
  "ruleNames": [
    "PEF 1.0",
    "Other"
  ]
}

4.9.1. Properties

"operator": "PEF"

"ruleNames": [
  "PEF 1.0",
  "PEF 2.0"
]

4.10. EmissionFactorSource

{
  "name": "ecoinvent",
  "version": "3.9.1"
}

4.10.1. Properties

"name": "ecoinvent"

"version": "3.9.1"

4.11. DataQualityIndicators

{
  "technologicalDQR": "5.0",
  "geographicalDQR": "2.0"
  "temporalDQR": "3.0",
}

4.11.1. Properties

4.12. Verification

{
  "coverage": "PCF program",
  "providerName": "My Auditor",
  "completedAt": "2025-04-08T14:47:32Z"
  "standardName": "ISO 14044"
}

4.12.1. Properties

4.13. Error

{ 
  "code": "NotFound",
  "message": "The requested footprint could not be found." 
}

4.13.1. Properties

5. HTTP REST API

5.1. Introduction

This section defines an HTTP-based API for the interoperable exchange of Product Footprint data between host systems.

The scope of the HTTP API is minimal by design. Additional features will be added in future versions of this specification.

5.2. Host System

A host system serves the needs of a single or multiple data owners. Additionally, a host system can also serve the needs of data recipients if it retrieves data from other host systems by calling their API.

In other words, any host system which implements the API endpoints as described in this specification can play the role of data owner as well as of data recipient, thus mirroring real-world supply chains. See § 6 Exchanging Footprints for more details.

A host system MUST implement the following actions:

• Action Authenticate

• Action ListFootprints

• Action GetFootprint

• Action Events

The host system MUST make footprints available for a data recipient through BOTH Action ListFootprints AND Action Events. Any product footprint obtained through an asynchronous request MUST also be retrievable through both synchronous methods, AND vice versa. This symmetry ensures any conformant host system in a supply chain can act as a data owner and a data recipient

A host system SHOULD implement access management to control what PCFs it accepts and makes available to which data recipients.

A host system MUST offer its actions over HTTPS only.

A host system MUST authenticate any client prior to using the above actions.

A host system SHOULD offer an OpenId Provider Configuration Document for the client to obtain the token endpoint for Action Authenticate.

A host system MUST offer all actions except Action Authenticate under the same Base URL, e.g. https://api.example.org/, or https://example.org/pact-api/ Note that for version 3 these actions can be found under $base-url$/3/...

A host system MAY offer the OpenId Provider Configuration Document or Action Authenticate under a different URL (Auth Base Url): $auth-base-url$/.well-known/openid-configuration or $auth-base-url$/auth/token. See § 5.5 Authentication Flow.

5.3. Out of scope

This standard focuses on the necessary definitions to enable interoperable data exchange between data owners and data recipients. This is mediated through a host system which implements the HTTP REST API defined in this document.

Within the PACT Project, conforming host systems are called solutions.

Solutions add further functionality on top of this standard in order to enable meaningful and interoperable data exchanges.

The following section briefly describes some of the additional functionality which is beyond the scope of this document:

1. Footprint calculation according to the PACT Methodology
2. Authentication and access management: the act of deciding and setting which product footprint may be accessed by each data recipient
3. Credentials management: the overall functionality to generate access credentials for data recipients, to exchange these credentials with data recipients, to rotate or revoke such credentials, etc.
4. Logging: creation and storage of access logs and audit trails related to data exchange, authentication processes, etc.

5.4. Error Handling

The actions GetFootprint, ListFootprints and Events MUST return an appropriate HTTP status code and MUST include a JSON Error object with information on the error.

Error responses are specified in detail such that data recipients can understand the cause of the error, and so that potentially host systems can act on and resolve errors automatically.

Error responses from Action Authenticate follow the OAuth specification [rfc6750]. See § 5.5 Authentication Flow

5.5. Authentication Flow

The API requires authentication using the OAuth 2.0 client credentials flow. Clients must obtain an access token before making requests to protected endpoints.

Host systems MUST implement this action in conformance with [rfc6749] Section 4.4.

5.5.1. Obtaining an Access Token

Clients SHOULD retrieve the token endpoint dynamically via the OpenID Connect discovery mechanism. The OpenID configuration can be found at:

$auth-base-url$/.well-known/openid-configuration

If provided by the host system, this document contains the token_endpoint to be used by the client.

If no OpenID configuration is provided by the host system, clients MUST assume $auth-base-url$/auth/token to be the token endpoint.

After determining the token endpoint, clients MUST obtain an access token by making a request to:

POST $token-endpoint$ 

with the following request parameters:

• grant_type: Must be set to client_credentials.

• client_id: The client’s unique identifier.

• client_secret: The client’s secret key.

Example request:

POST /auth/token HTTP/1.1
Host: id.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic {base64(client_id:client_secret)}

grant_type=client_credentials

5.5.2. Token Response

A successful response returns an access token in the following format:

{
  "access_token": "<token>",
  "token_type": "Bearer",
  "expires_in": 3600
}

If the client cannot be authenticated, the host system MUST respond with a 400 or 401 status code, and provide details on the error:

{
  "error": "invalid_client",
  "error_description": "Authentication failed"
}

For details and possible values for error see [rfc6749] section 5.2

5.5.3. Using the Access Token

Once obtained, the access token must be included in the Authorization header of API requests, following the OAuth 2.0 Bearer Token Usage standard (RFC 6750):

GET <base-url>/3/<action> HTTP/1.1
Authorization: Bearer <access_token>

The host system MUST check the Access Token and return a 401 when it has expired or is invalid.

Access tokens SHOULD expire. In this case, data recipients MUST retrieve a new access token as described in this section.

5.6. Action ListFootprints

GET /3/footprints?params=value&...

Retrieve a list of Product Carbon Footprints (PCFs) from the data owner. The data recipient can specify various criteria to filter the list, and the data owner can paginate the result set, if necessary.

Host systems SHOULD implement an access management system and only return the product footprints for which the data owner granted access to the requesting data recipient.

The host system SHOULD include footprints which have been deprecated in the resulting list of footprints, except if the status query parameter explicity requests only active footprints.

5.6.1. Pagination

1. The host system MUST NOT return more product footprints than requested in case a limit parameter was specified by a data recipient

2. The host system MUST return an HTTP Link header if there are additional ProductFootprints ready to be retrieved, such that

   • The Link header conforms to [RFC8288]

   • The value of the rel parameter is equal to next

   • the target URI of the Link header is absolute

   • The value of host of the target URI is equal to the value of the host request header from the original ListFootprints HTTP request

3. The target URI from the Link header is called a pagination link.

4. A pagination link MUST be valid for at least 180 seconds after creation

5. The data recipient CAN call the pagination link more than once

6. Upon each call, the host system

   • MUST NOT return more product footprints than requested in case limit was defined by a data recipient

   • MUST return a Link header conforming with the previous description in case there are additional ProductFootprints available

     link: <https://api.example.com/3/footprints?geography=FR&limit=10&offset=10>; rel="next"
     

7. If a response contains a second pagination link and the data recipient has called that second pagination link, the previous pagination link MAY no longer work: data recipients MUST NOT assume that previous pagination links continue to return results after advancing in the pagination process.

5.6.2. Filtering

The host system MUST support filtering of the list of footprints by criteria described under Parameters. Note that these are the same filters used by the § 5.8.1 Request Created Event Event.

A host system MAY provide additional filter criteria for the data recipient to use. These parameters MUST be prefixed with x-<identifier>-.

For example, to add functionality to search for product footprints based on an invoice number, a software solution could choose to support a parameter x-atq-invoice-id.

/3/footprints/?geography=FR&x-atq-invoice-id=12345&limit=100

the ODataV4 $filter syntax present in v2.x has been deprecated in v3.0.

5.6.3. Parameters

5.6.4. Responses

HTTP/1.1 200 OK
link: <https://api.example.com/3/footprints?geography=FR&limit=10&offset=10>; rel="next"
content-type: application/json

{
  "data": [ 
    {"id": "079e425a-464f-528d-341d-4a944a1dfd70", ... },
    {"id": "f4b1225a-bd44-4c8e-861d-079e4e1dfd69", ... }
    ...
  ]
}

{
  "data": [] // MUST NOT be null
}

5.7. Action GetFootprint

GET /3/footprints/{id}

Retrieve a single Product Carbon Footprint (PCF) by its unique identifier.

If the requested ProductFootprint is deprecated, the host system SHOULD return the deprecated ProductFootprint, if it is still available.

If the requested ProductFootprint is not found, the host system MUST return a 404 Not Found response.

Host systems SHOULD implement an access management system and only return the product footprints for which the data owner granted access to the requesting data recipient.

If it determines that a data recipient is not allowed to access the requested ProductFootprint, the host system MUST return a 403 Forbidden response.

5.7.1. Parameters

5.7.2. Responses

{
  "data": {
    "id": "079e425a-464f-528d-341d-4a944a1dfd70",
    "productIds": ["urn:pact:sample.com:product-id:44055-9c05bc35-68f8"]},
    "productNameCompany": "Sample Product",
    ...
  }
}

5.8. Action Events

POST /3/events

The Action Events endpoint supports the following use cases:

1. enabling a data recipient to request Product Footprints from a data owner by sending a RequestCreatedEvent, to which the data owner can answer by sending RequestFulfilledEvent or a RequestRejectedEvent.

2. enabling a data owner to notify a data recipient on updates to 1 or more Product Footprints: PublishedEvent

The Action Events endpoint accepts CloudEvent events (see [CE] and [CE-JSON]) encoded in "Structured Content Mode" (see [CE-Structured-Content-Mode]).

The CloudEvents are encoded in the "application/cloudevents+json" media type and MUST be sent as an HTTP POST request body to the Action Events endpoint.

The following events MUST be handled by the host system:

• RequestCreatedEvent

• RequestFulfilledEvent

• RequestRejectedEvent

• PublishedEvent

A host system MUST validate the event and return an HTTP 4xx status code if the event is invalid.

Upon accepting the event, the host system MUST return an HTTP 200 status code and SHOULD return an empty response body.

5.8.1. Request Created Event

A data recipient requests a ProductFootprint from the data owner. The data recipient MUST provide the criteria in the data object to enable the data owner to either find an existing relevant PCF or create a new one.

Criteria to provide can be product id, geography, company identifier, validity period, etc, see below for details.

If the data owner can immediately determine that it will not be able to handle this request it MUST respond with an appropriate 4xx error response, otherwise it MUST respond with a 200 (Success), indicating it will be able to process the request asynchronously.

Only in the latter case (after having accepted the request for processing) the data owner MUST send a follow-up event back to the data recipient at some time in the future. This follow up event MUST be either a RequestFulfilledEvent or RequestRejectedEvent.

Request Body

content-type: application/cloudevents+json

POST /3/events HTTP/1.1
Host: api.example.com
Content-Type: application/cloudevents+json
Authorizaton: Bearer xxxxxxxxxxxxx

{
  "type": "org.wbcsd.pact.ProductFootprint.RequestCreatedEvent.3",
  "specversion": "1.0",
  "id": "1934405d-4f9b-4b3b-9c05bc35-68f8",
  "source": "//api.example.com/3/events",
  "time": "2025-03-05T17:31:00Z",
  "data": {  
    "productId": ["urn:pact:sample.com:product-id:44055-9c05bc35-68f8"],
    "geography": ["DE"],
    "validAfter": "2025-01-01T00:00:00Z"
  }
}

5.8.2. Request Fulfilled Event

Notification that the request for PCF(s) has been fulfilled by the data owner. This notification will be sent by the data owner back to the data recipient in response to a ProductFootprintRequest.Created event, see § 5.8.1 Request Created Event.

The data object contains the original requestEventId and the resulting list of ProductFootprints which conform to the set of criteria specified by the data recipient in the preceding RequestCreated event. This list MUST be non-empty, as the RequestFulfilled event indicates success. The data owner MUST send a single RequestFulfilled event back to the data recipient per corresponding RequestCreated event.

If there are no product footprints to return, the data owner MUST send a § 5.8.3 Request Rejected Event instead.

If the data recipient cannot be reached by the data owner, the data owner SHOULD retry to send the event at a later time, using an exponential backoff strategy. It SHOULD abandon sending the event after 72 hours.

Request Body

content-type: application/cloudevents+json

POST /3/events HTTP/1.1
Host: api.example.com
Content-Type: application/cloudevents+json
Authorizaton: Bearer xxxxxxxxxxxxx

{
  "type": "org.wbcsd.pact.ProductFootprint.RequestFulfilledEvent.3",
  "specversion": "1.0",
  "id": "505e5d-4f9b-4b3b-9c05bc35-68f8",
  "source": "//api.example.com/3/events",
  "time": "2025-03-05T17:31:00Z",
  "data": {  
    "requestEventId": "1934405d-4f9b-4b3b-9c05bc35-68f8",
    "pfs": [
      { 
        /* ProductFootprint object */
        "id": "079e425a-464f-528d-341d-4a944a1dfd70",
        "specVersion": "3.0",
        "productIds": ["urn:pact:sample.com:product-id:44055-9c05bc35-68f8"], 
        ...
        "pcf": {
          ...
        }
      }, 
      { 
        "id": "079e425a-464f-528d-341d-4a944a1dfd71",
        ...
      }
    ]
  }
}

5.8.3. Request Rejected Event

Notification that a request for a ProductFootprint can not be fulfilled. The RequestRejectedEvent is an event sent back from the data owner to the data recipient upon NOT successfully fulfilling the preceding RequestCreatedEvent sent by the data recipient.

If the data recipient cannot be reached by the data owner, the data owner SHOULD retry to send the event at a later time, using an exponential backoff strategy. It SHOULD abandon sending the event after 72 hours.

Request Body

content-type: application/cloudevents+json

POST /3/events HTTP/1.1
Host: api.example.com
Content-Type: application/cloudevents+json
Authorizaton: Bearer xxxxxxxxxxxxx

{
  "type": "org.wbcsd.pact.ProductFootprint.RequestRejectedEvent.3",
  "specversion": "1.0",
  "id": "505e5d-4f9b-4b3b-9c05bc35-68f8",
  "source": "//api.example.com/3/events",
  "time": "2025-03-05T17:31:00Z",
  "data": {  
    "requestEventId": "1934405d-4f9b-4b3b-9c05bc35-68f8",
    "error": {
      "code": "NotFound",
      "message": "The requested footprint could not be found."
    }
  }
}

5.8.4. Published Event

Notification that a ProductFootprint has been published (either new or updated). This event is triggered by the data owner and send to relevant data recipients.

If the data recipient cannot be reached by the data owner, the data owner SHOULD retry to send the event at a later time, using an exponential backoff strategy. It SHOULD abandon sending the event after 72 hours.

The data object of the PublishedEvent contains the list of Product Footprint IDs that have been published or updated by the data owner.

The data recipient can retrieve the actual Product Footprints by calling the Action GetFootprint action on the data owner’s systems.

Request Body

content-type: application/cloudevents+json

"data": { 
  "pfIds": [ "uuid1", "uuid2", ... ] 
}

POST /3/events HTTP/1.1
Host: api.example.com
Content-Type: application/cloudevents+json
Authorizaton: Bearer xxxxxxxxxxxxx

{
  "type": "org.wbcsd.pact.ProductFootprint.PublishedEvent.3",
  "specversion": "1.0",
  "id": "1934405d-4f9b-4b3b-9c05bc35-68f8",
  "source": "//api.example.com/3/events",
  "time": "2022-05-31T17:31:00Z",
  "data": {
    "pfIds": ["079e425a-464f-528d-341d-4a944a1dfd70"]
  }
}

5.8.5. Responses

6. Exchanging Footprints

Note: This chapter is non-normative.

Achieving transparency in carbon emissions at the product level is challenging due to the complexity of global supply chains. This specification focuses on enabling transparency through a peer-to-peer PCF data exchange by specifying necessary aspects for achieving interoperability, such as the Data Model and API.

The PACT API supports two complementary methods for exchanging carbon footprint data, each designed for different use cases.

1. Synchronous Retrieval: Provides immediate access to carbon footprint data through direct API calls. This approach is ideal for:

• On-demand access to already existing PCFs

• Integration with applications requiring real-time data access

• Scenarios where the data recipient needs only to consume data (not receive updates)

2. Asynchronous Exchange: Enables event-based communication where PCF data can be requested, delivered, and updated over time. This approach is suited for:

   • Situations where a PCF may not be immediately available and needs time to be calculated

   • Workflows requiring notifications when new or updated PCF data becomes available

   • Complex supply chain scenarios where data may change over time

Both methods use the same underlying data model but differ in their communication patterns and implementation requirements.

The following sections describe each exchange method in detail, including the specific API actions, communication flows, and implementation considerations.

6.1. Synchronous Retrieval

The synchronous part of the PACT API allows for immediate retrieval of PCFs. Refer to § 5.6 Action ListFootprints and § 5.7 Action GetFootprint for detailed request and response formats.

6.1.1. Getting a single PCF

A data-recipient can directly obtain a given PCF by its ID by calling GetFootprint.

1. The data recipient authenticates with the data owner.

2. The data recipient calls the /footprints/{id} endpoint, providing the PCF ID (in UUID format)

3. If found, the data owner returns the PCF in ProductFootprint and HTTP status code 200. If not found a 404 (Not found) status code will be returned.

6.1.2. Getting multiple PCFs

The ListFootprints action allows for directly retrieving multiple PCFs. Starting from version 3.0, host systems must provide a way for data recipients to filter the resulting list, with a minimum set of criteria.

1. The data recipient authenticates with the data owner.

2. The data recipient calls the /footprints endpoint, optionally providing a filter with search criteria and a limit to obtain a list of PCFs.

3. After validating the request, the data owner returns a 2xx status code and the list of ProductFootprint objects. On error the data owner returns a relevant HTTP error code. For details, see § 5 HTTP REST API

6.2. Asynchronous Exchange

Exchanging PCFs asynchronously requires both the data owner and the data recipient to run a PACT conformant host system, both sides being able to initiate communication to each other.

6.2.1. Requesting a PCF

Generally, the data recipient sends a RequestCreatedEvent event to the data owner. The data owner will try to fullfil this request and, after some time, send the a RequestFullfilledEvent event back to the recipient.

1. The data recipient authenticates with the data owner.

2. The data recipient sends the RequestCreatedEvent event to the data owner, including criteria specifying which PCF it wants to receive, like product ID, reference period or geography.

3. The data owner validates the incoming event, directly returning a HTTP 2xx success code if OK, or a 4xx status code indicating error.

4. Asynchronously, the data owner will create a PCF or find an existing relevant PCF.

5. The data owner will authenticate with the data recipient and send either a RequestFullfilledEvent back with the PCF or a RequestRejectedEvent if it can not produce the PCF.

6.2.2. Sending an updated PCF

At any time after a data owner has sent a PCF to the data recipient, the data owner can send an update, for example because a PCF was updated or deprecated, or a new PCF was published, see § 7 Product Footprint Lifecycle.

In this case the data owner sends a PublishedEvent to the data recipient.

1. The data owner authenticates with the data recipient and sends a PublishedEvent with the updated or created PCF.

2. The data recipient should validate this incoming event and directly return a status code indicating succesful receipt (HTTP code 2xx) or an error (HTTP 4xx or 5xx).

Refer to § 5.8 Action Events for detailed request and response formats.

7. Product Footprint Lifecycle

7.1. Introduction

The contents of a ProductFootprint can change over time. For instance when a data owner publishes an updated Product Footprint ("upstream Product Footprints") which goes into the calculation of another Product Footprint ("downstream Product Footprint").

Even without upstream changes, a downstream Product Footprint can undergo changes in its own right, for instance when calculation errors are discovered and fixed, or when secondary emission databases are updated.

This section defines how changes to Product Footprints shall be handled by data owners and communicated to data recipients through the ProductFootprint data model.

Starting with version 3.0, any change to a Product Footprint will result in a new Product Footprint with a new ID. The previous Product Footprint will be marked as Deprecated. The properties version, updated and statusComment are now obsolete.

7.2. Change Definition and Handling

A change to a Product Footprint is defined as a change to one or more properties of a ProductFootprint, including a change of properties from being undefined to defined or vice-versa.

After creation of a ProductFootprint this footprint MUST NOT be changed, EXCEPT for changing its status property to Deprecated

A ProductFootprint with status Deprecated MUST NOT be changed anymore.

7.2.1. Updating PCFs

Starting with version 3.0, a change to any part of the footprint MUST result in a new footprint with a new id. The old id SHOULD be added to the PrecedingPfIds list to be able to track back to the previous version. The old PCF MUST have its status set to Deprecated.

7.2.2. Deprecating PCFs

If a PCF becomes obsolete the status property of the PCF needs to be set to Deprecated. Note that this is the only occasion after creation that an already existing PCF will and MUST change.

7.2.3. Obsolete Properties

Starting with version 3.0, the following properties are now obsolete and have been removed from the ProductFootprintL:

• version

• updated

• statusComment

7.3. Validity Period

The validity period is the time interval during which the ProductFootprint is declared as valid for use by a receiving data recipient.

The validity period is OPTIONAL defined by the properties validityPeriodStart (including) and validityPeriodEnd (excluding).

If a validity period is specified, it is restricted to a time window between referencePeriodEnd and referencePeriodEnd + 3 years:

• If specified, validityPeriodStart MUST be greater than or equal to referencePeriodEnd.

• If validityPeriodEnd is specified it MUST be less than or equal to referencePeriodEnd + 3 years.

If no validity period is specified, the ProductFootprint is valid for 3 years starting with referencePeriodEnd.

8. Product Identification and Classification

To exchange PCF data between organizations, it is necessary to identify the related product or material. Given data owners and data recipients do not always (or often) use the same identification schemes, commonly and uniquely identifying the same product is a challenge - especially at scale. Given this situation, organizations must perform laborious and manual “mapping” exercises to map their identifier(s) for a product to the identify their supplier can understand.

This specification describes how the product ID URN (Uniform Resource Name) should be constructed in cases where no formal namespace for a given product identifier is defined.

This will not eliminate the need for a mapping process but will ease mapping identifiers with a common, easily understood structure. Further, this proposal ensures interoperability with industry-specific product identifiers.

We recognize there are existing relevant namespaces and corresponding URN syntax specifications. These can either be IANA-registered namespaces (like urn:ISBN) or widely used standards like urn:gtin. When product identification based on one or more of these standards is applicable, the corresponding namespaces should be used.

Similar to product identifiers, product classifiers contain URNs, using well-known namespaces when applicable, or a custom pact namespace if needed.

8.1. Product Identifier URN’s

urn:namespace:namespace-specific-string

In determining which URN namespace and corresponding syntax to use, the data owner SHOULD follow the reasoning below:

1. If an IANA-registered URN namespace exists and is applicable, this SHOULD be used. See IANA Registered Namespaces for existing specifications, like ISBN.

2. If a widely used URN schema exists and is applicable, this SHOULD be used, for example GTIN product identifiers.

3. If the data owner wishes to use a product identifier for which an existing URN specification does not exist, the data owner SHOULD use the following format:

   urn:pact:$domain-of-issuer$:$identifier-type$:$id$
   

   • urn:pact: is the fixed sub-string to identify the URN namespace.

   • $domain-of-issuer$ is the fully qualified domain name [RFC1035] of the organization issuing the identifier. Ideally the fully qualified domain points to the product specification. For example: catalog.mycompany.com

   • $identifier-type$ defines the kind of product identifier being specified. This brings clarity to the recipient to understand what kind of identifier is provided.

   • $id$ is the actual id of the product within this context. This can be any string uniquely identifying the product.

   The following $identifier-type$ values are recommended.

   $identifier-type$	Description	Notes
   product-id	Specifies a product id from a third-party organization, standard, etc.	Use this identifier-type when no other, more specific one is applicable.
   buyer-id	Specifies a product id created by the buyer, aka data recipient.	This is the equivalent of "buyer-assigned" as referenced in Tech Specs V2.
   supplier-id	Specifies a product id created by the supplier, aka data owner.	This is the equivalent of "vendor-assigned" as referenced in Tech Specs V2.

   This is a non-exhaustive list of $identifier-type$. This set MAY be extended in minor versions of the standard release. Organizations may contact PACT to propose additional $identifier-type$ for consideration to be added as recommended industry-agnostic identifiers.

   Organizations and industry initiatives are encouraged to define the relevant $identifier-type$ for products within their industry separately.

8.1.1. Examples

Below is a list of examples of productIds as used in the ProductFootprint data type clarifying the use of well-known and custom URN namespaces for identifying products.

["urn:pact:sample.com:product-id:44055-9c05bc35-68f8"]
["urn:pact:sample-buyer.com:buyer-id:103403453"]
["urn:pact:sample-supplier.com:supplier-id:1234"]

["urn:isbn:978-951-0-18435-6"]

["urn:gtin:4712345060507"]

["urn:uuid:69585GB6-56T9-6958-E526-6FDGZJHU1326"]

["urn:pact:sigmaaldrich.com:supplier-id:14021",
"urn:pact:cas.org:substance-number:13463-67-7",
"urn:pact:iupac.org:substance-name:dioxotitanium",
"urn:pact:inchi-trust.org:substance-id:1S,/2O.Ti",
"urn:pact:inchi-trust.org:substance-key:
GWEVSGVZZGPLCZ-UHFFFAOYSA-N"]

8.2. Product Classification URNs

Similar to product identifiers any product classification MUST be a URN as specified in [RFC8141]:

urn:namespace:namespace-specific-string

In determining which URN namespace and corresponding syntax to use, the data owner SHOULD follow the reasoning below:

1. If an IANA-registered URN namespace exists and is applicable, this SHOULD be used. See IANA Registered Namespaces for existing specifications. Example: 'urn:iso'

2. If a widely used URN namespace exists and is applicable, this SHOULD be used.

3. If the data owner wishes to use a product identifier for which an existing URN specification does not exist, the data owner SHOULD use the following format:

   urn:pact:$domain-of-issuer$:$type$:$value$

   • urn:pact: is the fixed sub-string to identify the URN Namespace. Based on feedback from the community we propose the use of pact as the recommended namespace.

   • $domain-of-issuer$ is the fully qualified domain name of the organization issuing the category identifier. The issuer of the code can be an organization, company or industry initiative. Example: categories.mycompany.com

   • $type$ defines the kind of product category or classification being specified. This brings clarity to the recipient to understand what kind of classification is provided.

8.2.1. Examples

["urn:pact:cas.org:substance-number:13463-67-7"]

["urn:pact:inchi-trust.org:substance-id:$INCHI-ID$"]

"urn:pact:catalog.company.com:category-id:550010"

"urn:cpc:0151"

"urn:unspsc:43211507"

"urn:eclass:28070000"

"urn:iso:std:iso:4217"

These namespaces allow systems and standards to consistently identify and categorize products, making them useful in a variety of domains like supply chain management, retail, industrial procurement, and publication. If you’re working with a specific product categorization system, you may find these URNs particularly relevant for classification or reference purposes.

9. Examples

9.1. Example Action ListFootprints

GET /3/footprints?limit=10 HTTP/2
host: api.example.org
authorization: Bearer [BearerToken]

HTTP/1.1 200 OK
date: Mon, 23 May 2025 19:33:16 GMT
content-type: application/json
content-length: 1831
link: <https://api.example.org/3/footprints?limit=10&offset=10>; rel="next"

{
  "data": [
    {
      "id": "91715e5e-fd0b-4d1c-8fab-76290c46e6ed",
      "specVersion": "3.0.0",
      "version": 1,
      "created": "2025-03-01T09:32:20Z",
      "status": "Active",
      "validityPeriodStart": "2025-03-01T09:32:20Z",
      "validityPeriodEnd": "2026-12-31T00:00:00Z",
      "companyName": "My Corp",
      "companyIds": [
        "urn:uuid:69585GB6-56T9-6958-E526-6FDGZJHU1326",
        "urn:epc:id:sgln:562958.00000.4"
      ],
      "productDescription": "Bio-Ethanol 98%, corn feedstock (bulk - no packaging)",
      "productIds": ["urn:gtin:5695872369587"],
      "productClassifications": ["urn:pact:productclassification:un-cpc:1234"],
      "productNameCompany": "Green Ethanol",
      "comment": "",
      "pcf": {
        "declaredUnitOfMeasurement": "liter",
        "declaredUnitAmount": "1",
        "productMassPerDeclaredUnit": "0.879",
        "pcfExcludingBiogenicUptake": "1.85",
        "pcfIncludingBiogenicUptake": "1.63",
        "fossilGhgEmissions": "1.5",
        "fossilCarbonContent": "0",
        "biogenicCarbonContent": "0.41",
        "landManagementBiogenicCO2Emissions": "0.6",
        "landManagementBiogenicCO2Removals": "-0.4",
        "biogenicCO2Uptake": "-1.5",
        "aircraftGhgEmissions": "0.2",
        "ipccCharacterizationFactors": ["AR6"],
        "crossSectoralStandards": [
          "GHGP-Product",
          "ISO14067"
        ],
        "productOrSectorSpecificRules": [
          {
            "operator": "Other",
            "ruleNames": [
              "The Product Carbon Footprint Guideline for the Chemical Industry, v.2.0"
            ],
            "otherOperatorName": "Tfs"
          }
        ],
        "biogenicAccountingMethodology": "GHPG",
        "boundaryProcessesDescription": "1) Material acquisition and preprocessing, including growth of corn 2) Production: fuel consumption, electricity consumption, water consumption, process-generated direct emissions 3) Distribution and storage: transportation of the finished product from manufacturing site to storage site",
        "referencePeriodStart": "2024-01-01T00:00:00Z",
        "referencePeriodEnd": "2026-01-01T00:00:00Z",
        "geographyRegionOrSubregion": "Western Europe",
        "secondaryEmissionFactorSources": [
          {
            "name": "Ecoinvent",
            "version": "3.1"
          }
        ],
        "exemptedEmissionsPercent": "0",
        "exemptedEmissionsDescription": "",
        "allocationRulesDescription": "Using mass allocation following the product specific rule as per PACT Framework decision-making tree",
        "primaryDataShare": "12.9",
        "dqi": {
          "technologicalDQR": "1.6",
          "temporalDQR": "2.6",
          "geographicalDQR": "1.8"
        }
      },
      "extensions": [
        {
          "specVersion": "3.0.0",
          "dataSchema": "https://example.org/schemas/shipment/1.0.0/data-model.json",
          "data": {
            "shipmentId": "S1234567890",
            "consignmentId": "Cabc.def-ghi",
            "shipmentType": "PICKUP",
            "weight": 10,
            "transportChainElementId": "ABCDEFGHI"
          }
        }
      ]
    }
  ]
}

{
  "data": []
}

9.2. Example Action GetFootprint

GET /3/footprints/91715e5e-fd0b-4d1c-8fab-76290c46e6ed HTTP/2
host: api.example.org
authorization: Bearer [BearerToken]

HTTP/1.1 200 OK
date: Mon, 23 May 2025 19:33:16 GMT
content-type: application/json

{
  "data": {
    "id": "91715e5e-fd0b-4d1c-8fab-76290c46e6ed",
    "specVersion": "3.0.0",
    "version": 1,
    "created": "2024-03-01T09:32:20Z",
    "status": "Active",
    "validityPeriodStart": "2024-03-01T09:32:20Z",
    "validityPeriodEnd": "2025-12-31T00:00:00Z",
    "companyName": "My Corp",
    "companyIds": [
      "urn:uuid:69585GB6-56T9-6958-E526-6FDGZJHU1326",
      "urn:epc:id:sgln:562958.00000.4"
    ],
    "productDescription": "Bio-Ethanol 98%, corn feedstock (bulk - no packaging)",
    "productIds": ["urn:gtin:5695872369587"],
    "productClassifications": ["urn:pact:productclassification:un-cpc:1234"],
    "productNameCompany": "Green Ethanol",
    "comment": "",
    "pcf": {
      "declaredUnitOfMeasurement": "liter",
      "declaredUnitAmount": "1",
      "productMassPerDeclaredUnit": "0.879",
      "pcfExcludingBiogenicUptake": "1.85",
      "pcfIncludingBiogenicUptake": "1.63",
      "fossilGhgEmissions": "1.5",
      "fossilCarbonContent": "0",
      "biogenicCarbonContent": "0.41",
      "landManagementBiogenicCO2Emissions": "0.6",
      "landManagementBiogenicCO2Removals": "-0.4",
      "biogenicCO2Withdrawal": "-1.5",
      "aircraftGhgEmissions": "0.2",
      "ipccCharacterizationFactors": ["AR6"],
      "crossSectoralStandards": [
        "GHGP-Product",
        "ISO14067"
      ],
      "productOrSectorSpecificRules": [
        {
          "operator": "Other",
          "ruleNames": [
            "The Product Carbon Footprint Guideline for the Chemical Industry, v.2.0"
          ],
          "otherOperatorName": "Tfs"
        }
      ],
      "biogenicAccountingMethodology": "GHPG",
      "boundaryProcessesDescription": "1) Material acquisition and preprocessing, including growth of corn 2) Production: fuel consumption, electricity consumption, water consumption, process-generated direct emissions 3) Distribution and storage: transportation of the finished product from manufacturing site to storage site",
      "referencePeriodStart": "2024-01-01T00:00:00Z",
      "referencePeriodEnd": "2026-01-01T00:00:00Z",
      "geographyRegionOrSubregion": "Western Europe",
      "secondaryEmissionFactorSources": [
        {
          "name": "Ecoinvent",
          "version": "3.1"
        }
      ],
      "exemptedEmissionsPercent": "0",
      "exemptedEmissionsDescription": "",
      "allocationRulesDescription": "Using mass allocation following the product specific rule as per PACT Framework decision-making tree",
      "primaryDataShare": "12.9",
      "dqi": {
        "technologicalDQR": "1.6",
        "temporalDQR": "2.6",
        "geographicalDQR": "1.8"
      },
      "verification": {
        "providerName": ""
      }
    },
    "extensions": [
      {
        "specVersion": "3.0.0",
        "dataSchema": "https://catalog.carbon-transparency.org/shipment/1.0.0/data-model.json",
        "data": {
          "shipmentId": "S1234567890",
          "consignmentId": "Cabc.def-ghi",
          "shipmentType": "PICKUP",
          "weight": 10,
          "transportChainElementId": "ABCDEFGHI"
        }
      }
    ]
  }
}

9.3. Example Error Response

GET /3/footprints/91715e5e-fd0b-4d1c-8fab-76290c46e6ed HTTP/2
host: api.example.org
authorization: Bearer [BearerToken]

HTTP/1.1 403 Forbidden
date: Mon, 23 May 2025 19:33:16 GMT
content-type: application/json
content-length: 44

{
  "code": "AccessDenied",
  "message": "Access Denied"
}

9.4. Example Action Events

Example ProductFootprint.RequestCreated

POST /3/events HTTP/1.1
host: api.example.org
authorization: Bearer [BearerToken]
content-type: application/cloudevents+json; charset=UTF-8

{
  "type": "org.wbcsd.pact.ProductFootprint.RequestCreated.3",
  "specversion": "1.0",
  "id": "848dcf00-2c18-400d-bcb8-11e45bbf7ebd",
  "source": "//api.recipient.org/3/events",
  "time": "2024-11-06T16:23:00Z",
  "data": {
      "productId": ["urn:gtin:4712345060507"],
      "geography": ["DE"],
      "comment": "Please provide current PCF value."
  }
}

HTTP/1.1 200 OK
content-length: 0

Example ProductFootprint.RequestFulfilled

POST /3/events HTTP/1.1
host: api.recipient.org
authorization: Bearer [BearerToken]
content-type: application/cloudevents+json; charset=UTF-8

{
  "type": "org.wbcsd.pact.ProductFootprint.RequestFulfilledEvent.3",
  "specversion": "1.0",
  "id": "5afe8fbf-0ea9-477c-a1df-2d3c95f7eec0",
  "source": "//api.example.org/events",
  "time": "2024-11-08T13:26:00Z",
  "data": {
    "requestEventId": "848dcf00-2c18-400d-bcb8-11e45bbf7ebd",
    "pfs": [
      {
        "id": "91715e5e-fd0b-4d1c-8fab-76290c46e6ed",
        "specVersion": "3.0.0",
        "version": 1,
        "created": "2024-03-01T09:32:20Z",
        "status": "Active",
        "validityPeriodStart": "2024-03-01T09:32:20Z",
        "validityPeriodEnd": "2026-12-31T00:00:00Z",
        "companyName": "My Corp",
        "companyIds": [
          "urn:uuid:69585GB6-56T9-6958-E526-6FDGZJHU1326",
          "urn:epc:id:sgln:562958.00000.4"
        ],
        "productDescription": "Bio-Ethanol 98%, corn feedstock (bulk - no packaging)",
        "productIds": ["urn:gtin:5695872369587"],
        "productClassifications": ["urn:pact:productclassification:un-cpc:1234"],
        "productNameCompany": "Green Ethanol",
        "comment": "",
        "pcf": {
          "declaredUnitOfMeasurement": "liter",
          "declaredUnitAmount": "1",
          "productMassPerDeclaredUnit": "0.879",
          "pcfExcludingBiogenicUptake": "1.85",
          "pcfIncludingBiogenicUptake": "1.63",
          "fossilGhgEmissions": "1.5",
          "fossilCarbonContent": "0",
          "biogenicCarbonContent": "0.41",
          "landManagementBiogenicCO2Emissions": "0.6",
          "landManagementBiogenicCO2Removals": "-0.4",
          "biogenicCO2Uptake": "-1.5",
          "aircraftGhgEmissions": "0.2",
          "ipccCharacterizationFactors": ["AR6"],
            "crossSectoralStandards": [
            "GHGP-Product",
            "ISO14067"
          ],
          "productOrSectorSpecificRules": [
            {
              "operator": "Other",
              "ruleNames": [
                "The Product Carbon Footprint Guideline for the Chemical Industry, v.2.0"
              ],
              "otherOperatorName": "Tfs"
            }
          ],
          "biogenicAccountingMethodology": "GHPG",
          "boundaryProcessesDescription": "1) Material acquisition and preprocessing, including growth of corn 2) Production: fuel consumption, electricity consumption, water consumption, process-generated direct emissions 3) Distribution and storage: transportation of the finished product from manufacturing site to storage site",
          "referencePeriodStart": "2023-01-01T00:00:00Z",
          "referencePeriodEnd": "2026-01-01T00:00:00Z",
          "geographyRegionOrSubregion": "Western Europe",
          "secondaryEmissionFactorSources": [
            {
              "name": "Ecoinvent",
              "version": "3.1"
            }
          ],
          "exemptedEmissionsPercent": "0",
          "exemptedEmissionsDescription": "",
          "allocationRulesDescription": "Using mass allocation following the product specific rule as per PACT Framework decision-making tree",
          "primaryDataShare": "12.9",
          "dqi": {
            "technologicalDQR": "1.6",
            "temporalDQR": "2.6",
            "geographicalDQR": "1.8"
          },
          "verification": {
            "providerName": ""
          }
        },
        "extensions": [
          {
            "specVersion": "3.0.0",
            "dataSchema": "https://catalog.carbon-transparency.org/shipment/1.0.0/data-model.json",
            "data": {
              "shipmentId": "S1234567890",
              "consignmentId": "Cabc.def-ghi",
              "shipmentType": "PICKUP",
              "weight": 10,
              "transportChainElementId": "ABCDEFGHI"
            }
          }
        ]
      }
    ]
  }
}

HTTP/1.1 200 OK
content-length: 0

Appendix A: Changelog

Version 3.0.0 (Apr 30, 2025)

Summary of major changes since version 2.3:

1. API and Documentation Improvements

   • Description of API methods and responses is now generated from the OpenAPI specification

   • Simplified Host system requirements

   • Simplified Authentication section

   • Added Error handling section

   • Added information on retry strategy for RequestFulfilledEvent, RequestRejectedEvent, PublishedEvent

   • Clarity on definition of change

2. Framework and Methodology Enhancements

   • Simplified versioning (ADR-41) included in § 7 Product Footprint Lifecycle

   • Simplified filtering for Sync and Async API (ADR-42)

   • Common URN structure for product ids and classification id’s (ADR-34)

   • Updated references to the PACT Framework 3.0

   • Added paragraph on § 7.3 Validity Period to § 7 Product Footprint Lifecycle

3. Carbon Accounting Model Improvements

   • Add Biogenic Emissions and Removals (ADR-45)

   • Include attributes for CCU (Carbon Capture and Utilization) (ADR-46)

   • Consistent typing of real numbers (ADR-39)

   • Additional units for service-related footprints (ADR-40)

   • Clarification of unit of measurement and product amount (ADR-36)

4. Data Model Changes: Properties added:

   • declaredUnitOfMeasurement

   • declaredUnitAmount

   • pcfExcludingBiogenicUptake

   • pcfIncludingBiogenicUptake

   • biogenicNonCO2Emissions

   • biogenicCO2Uptake

   • landUseChangeGhgEmissions

   • landCarbonLeakage

   • landManagementBiogenicCO2Emissions

   • landManagementBiogenicCO2Removals

   • landManagementFossilGhgEmissions

   • landAreaOccupation

   • technologicalCO2CaptureOrigin

   • technologicalCO2Removals

   • ccsTechnologicalCO2CaptureIncluded

   • ccsTechnologicalCO2Capture

   • ccuCreditCertification

   • ccuCalculationApproach

   • ccuCarbonContent

   • outboundLogisticsGhgEmissions

   • ipccCharacterizationFactors

   • recycledCarbonContent

   • packagingBiogenicCarbonContent

   • verification

   Properties removed:

   • ProductFootprint/productCategoryCpc (deprecated in 2.3, superseded by productClassifications)

   • ProductFootprint/statusComment

   • CarbonFootprint/declaredUnit (replaced by declaredUnitOfMeasurement)

   • CarbonFootprint/UnitaryProductAmount (replaced by declaredUnitAmount)

   • CarbonFootprint/pCfIncludingBiogenic (superseded by pcfIncludingBiogenicUptake)

   • CarbonFootprint/pCfEncludingBiogenic (superseded by pcfExcludingBiogenicUptake)

   • CarbonFootprint/dLucGhgEmissions

   • CarbonFootprint/iLucGhgEmissions

   • CarbonFootprint/landManagementGhgEmissions

   • CarbonFootprint/biogenicCarbonWithdrawal

   • CarbonFootprint/otherBiogenicGhgEmissions

   • CarbonFootprint/crossSectoralStandardsUsed (deprecated in 2.3, replaced by CarbonFootprint/crossSectoralStandards)

   • CarbonFootprint/characterizationFactors (deprecated in 2.2, replaced by CarbonFootprint/ipccCharacterizationFactors)

   • CarbonFootprint/uncertaintyAssessmentDescription

   • DataQualityIndicators/coveragePercent

   • DataQualityIndicators/reliabilityDQR

   • DataQualityIndicators/completenessDQR

   Properties and types renamed:

   • CarbonFootprint/assurance renamed to verification

   Properties with changed optionality:

   • Property boundaryProcessesDescription now optional (ADR31)

   • Property exemptedEmissionsDescription now optional (ADR31)

   • Assurance/providername now optional

   Data type changes:

   • Consistent Decimal typing for all fractional numbers (ADR39). The following fields changed from Number to Decimal:

     • primaryDataShare

     • exemptedEmissionsPercent

     • technologicalDQR

     • geographicalDQR

     • temporalDQR

   • DQR ratings technologicalDQR, temporalDQR, geographicalDQR now range between 1 and 5

Version 2.3.0 (Oct 24, 2024)

Summary of changes:

1. Rebranding: Sunset the Pathfinder name, replacing "Pathfinder Framework" with "PACT Methodology" and "Pathfinder Network" with "PACT Network".

2. Product Identifiers:

• Added chapter § 8 Product Identification and Classification including specification and examples for a common URN namespace syntax for productIds (ADR34)

• Included URN namespace syntax for product classifications (ADR37)

• Added optional property productClassifications (ADR37)

• Advisement that property ProductFootprint/productCategoryCpc will be deprecated in version 3 (ADR37)

3. Terminology and Attribute Changes:

• Replaced the term 'reporting period' with 'reference period' for consistency with the attributes referencePeriodStart and referencePeriodEnd

• Revised productDescription to be more descriptive, following decision to keep attribute as mandatory

• Indicated deprecation of crossSectoralStandardsUsed and introduction of crossSectoralStandards, reflecting consensus reached on ADR32

• Added advisement that piece will be added as a DeclaredUnit in v3

• Added attribute productMassPerDeclaredUnit, per consensus reached on ADR33

• Clarified ProductFootprint/statusComment attribute to include descriptive reasoning behind a given change in status

Version 2.2.1 (June 24, 2024)

Summary of changes:

1. Documentation Improvements:

   • Added diagram with visual representation of asynchronous event processing workflow

   • Fixed § 9.1 Example Action ListFootprints, § 9.4 Example Action Events, § 9.2 Example Action GetFootprint, and § 6 Exchanging Footprints by removing spurious geographicScope object

   • Fixed dqi value types in all examples

   • Fixed DataQualityIndicators by removing misleading link to decimal

2. Definition Clarifications:

   • Clarified aircraftGhgEmissions definition to make it explicit that radiative forcing is excluded

Version 2.2.0 (Apr 10, 2024)

Summary of changes:

1. Documentation Improvements:

   • Addition of the new § 6 Exchanging Footprints chapter

   • Addition of missing examples in the § 6 Exchanging Footprints section

   • Fixed the incomplete assurance example and moved it to the appropriate section

   • Fixed the incorrect value of pCfExcludingBiogenic in all relevant examples

   • Removal of notes referring to the transition from v1 to v2

2. API and Event Processing Updates:

   • Updates to Action Events implementation requirement - changed from OPTIONAL to MANDATORY

   • Clarification of PF Request Event syntax, including the instruction that the ProductFootprintFragment should refer to one single product

   • Addition of a recommendation to include ProductIds in the PF Request Event request body

   • Addition of Examples of a PCF request and response Action Event flow

   • Addition of an Example for a ProductFootprintFragment indicating a query for a PCF via productId

   • Clarification of how to handle error codes in Action ListFootprints and Action GetFootprints

   • Fixed example 28’s HTTP error code (from 401 to 400) in accordance with [rfc6749]

3. Data Model Changes:

   • Deprecation of the CarbonFootprint/characterizationFactors property

   • Addition of a new CarbonFootprint/ipccCharacterizationFactorsSources property

4. Future Version Advisements:

   • Addition of advisement to exemptedEmissionsPercent stating that the upper boundary will be removed in version 3

   • Addition of advisements to properties ProductFootprint/productCategoryCpc, comment, boundaryProcessesDescription, and exemptedEmissionsDescription stating that they will become OPTIONAL in version 3

Version 2.1.0 (Dec 07, 2023)

This version introduces additional mandatory functionality:

1. A new authentication flow (§ 5.5 Authentication Flow) is specified which allows discovery of token endpoint through an OpenId Provider Configuration Document. The flow is backwards-compatible with the 2.0.x-series of authentication flow based on the /auth/token syntax.

Version 2.0.1 (Oct 26, 2023)

Summary of changes:

1. Data Model Corrections and Clarifications:

   • Fixed definition discrepancies between the Pathfinder Framework Version 2 and the specification:

   • boundaryProcessesDescription: Corrected from optional to mandatory

   • primaryDataShare: Marked as O* instead of O to align with Framework

   • dqi: Resolved discrepancy with Framework - updated to indicate at least one of primaryDataShare or dqi must be defined (not mutually exclusive)

   • Unit corrections:

   • fossilCarbonContent: Changed unit from kg of CO2e / declaredUnit to kg / declaredUnit and further clarified as kgC / declaredUunit

   • biogenicCarbonContent: Changed unit from kg of CO2e / declaredUnit to kg / declaredUnit and further clarified as kgC / declaredUunit

   • Value constraint corrections:

   • CarbonFootprint/landManagementGhgEmissions: Fixed incorrect definition as non-negative decimal

   • CarbonFootprint/biogenicCarbonWithdrawal: Fixed incorrect definition as non-negative decimal, clarified must be equal to 0 or less than 0

   • Additional clarifications to:

   • CarbonFootprint/fossilGhgEmissions

   • CarbonFootprint/pCfExcludingBiogenic

   • CarbonFootprint/pCfIncludingBiogenic

   • CarbonFootprint/biogenicCarbonWithdrawal

2. Assurance Data Type Updates:

   • Documentation fix to Assurance/coverage: Changed from mandatory (M) to optional (O)

   • Added property Assurance/assurance in accordance with Framework

3. API and Documentation Improvements:

   • Clarified error responses for Action Authenticate endpoint with example error responses following [rfc6749]

   • Added references to SI Units for data type DeclaredUnit

   • Clarified filter processing semantics in § 5.6 Action ListFootprints with new § 5.6.2 Filtering section

   • Fixed referencePeriod in Filter Example

   • Fixed typo in referencePeriodEnd definition

   • Clarified host system requirements for HTTP error status codes when events endpoint is not implemented

   • Clarified the PCF term definition

   • Fixed linking to semantic versioning document

   • Reworded referencePeriodStart and referencePeriodEnd

   • Minor documentation improvements to status

   • Added an advisement to CarbonFootprint/biogenicAccountingMethodology

   • Updated section § 4.11 DataQualityIndicators to reference Table 9 of the Pathfinder Framework

   • Fixed formatting of productDescription definition

Version 2.0.0 (Feb 20, 2023)

Summary of the major changes and concepts added with this version:

1. update to Pathfinder Framework Version 2.0, including data model changes which are not backwards-compatible, including

   1. addition of data type DataQualityIndicators and Assurance to CarbonFootprint

2. event-based communication between host systems (§ 5.8 Action Events)

3. support for data model extensions (§ 4.8 DataModelExtension)

4. life cycle management of a ProductFootprint (§ 7 Product Footprint Lifecycle)

Data Model Changes

Overview of the changes to the data model compared with the data model version 1.0.1:

• changes to data type ProductFootprint:

• properties validityPeriodStart and validityPeriodEnd: added

• life cycle properties precedingPfIds, status and ProductFootprint/statusComment: added

• addition of data type DataQualityIndicators to CarbonFootprint via property dqi

• addition of data type Assurance to CarbonFootprint via property CarbonFootprint/assurance

• changes to data type CarbonFootprint:

• property CarbonFootprint/characterizationFactors: added

• property CarbonFootprint/exemptedEmissionsPercent: added

• property CarbonFootprint/primaryDataShare: was mandatory is now optional

• property CarbonFootprint/pCfExcludingBiogenic: added

• property CarbonFootprint/pCfIncludingBiogenic: added

• property fossilCarbonContent: added

• property CarbonFootprint/biogenicCarbonWithdrawal: added

• property CarbonFootprint/biogenicAccountingMethodology: added

• property packagingEmissionsIncluded: added

• property exemptedEmissionsDescription: added

• property packagingGhgEmissions: added

• property CarbonFootprint/uncertaintyAssessmentDescription: added

• property reportingPeriodStart: renamed to referencePeriodStart

• property reportingPeriodEnd: renamed to referencePeriodEnd

• property emissionFactorSources: renamed to secondaryEmissionFactorSources

• property aircraftGhgEmissions: added

• changes to data type BiogenicEmissions:

• all properties moved to CarbonFootprint and the data type removed fully, plus

• property landUseChangeGhgEmissions substituted with properties CarbonFootprint/iLucGhgEmissions and CarbonFootprint/dLucGhgEmissions

• property landUseEmissions renamed to CarbonFootprint/landManagementGhgEmissions

• property otherEmissions renamed to CarbonFootprint/otherBiogenicGhgEmissions

• data type CompanyId: added, including instructions on custom company codes

• changes to data type ProductId: addition of instructions for CAS, InChi and custom URNs.

API Changes

• Action ListFootprints:

  1. rename of HTTP query parameter filter to $filter

  2. introduce additional allowed $filter operators and properties:

     • Additional operators: eq, lt, le, gt, and, any

     • Additional properties: created, ProductFootprint/updated, ProductFootprint/productCategoryCpc, geographyCountry, referencePeriodStart, referencePeriodEnd, companyIds, productIds.

  3. Addition of alternative Action ListFootprints response HttpStatusCode 202, and pull-based request/response semantics

  4. pagination is now mandatory. See § 5.6.1 Pagination

• Action Events: section § 5.8 Action Events added

Version 1.0.1

The following changes have been applied for version 1.0.1

1. Addition of data type RegionOrSubregion, cleaning up the definition of property geographyRegionOrSubregion

2. Fix to the JSON representation specification in crosssectoralstandardset-json

3. Change to the minimum size of the set productOrSectorSpecificRules from 0 to 1, aligning with the overall specification.

4. Removal of unreferenced data type Boolean from the data model section

5. Rewording, simplified wording of chapter § 5.5 Authentication Flow

6. Addition of an authentication flow specification in chapter § 5.5 Authentication Flow

7. Improved wording of request parameter Filter in section § 5.6 Action ListFootprints

8. Improved wording in section § 5.4 Error Handling, specifically

   • addition of error response definition

   • improved specification of the error response JSON representation

   • consolidated specification of overall error response representation as a HTTP Response

   • improvements to previous subsection "List of error codes", plus merging into overall section § 5.4 Error Handling

   • addition of list of example situations when an error response is returned

9. Addition of Section § 9.3 Example Error Response

10. Addition of term interoperable to section § 2 Terminology, plus linking to in respective sections

11. Addition of Terms UN geographic region and UN geographic subregion

12. Introduction of a new property table layout in section § 4.7 CarbonFootprint and § 4.6 ProductFootprint

13. Removal of data types PositiveDecimal, SpecVersionString, VersionInteger