PCF Screen

Climatiq’s PCF Screen endpoint lets you create screening-level product carbon footprints using whatever data you have available. At a minimum, the endpoint requires a product name and manufacturing location. You can improve calculation results by adding manufacturing year, finished product weight, or any other product details as free text.

The endpoint uses AI to generate assumptions about the product, such as the product composition, sourcing regions, manufacturing processes, or energy use. These assumptions are used to calculate the PCF screen. You can edit, replace and iterate on the PCF as you receive better product data, using the Estimate endpoint.

POST This endpoint allows you to create a full preliminary Product Carbon Footprint with minimal input data.

https://api.climatiq.io/pcf/v1-preview2/screen

Request

Example request:

curl --request POST \
  --url https://api.climatiq.io/pcf/v1-preview2/screen \
  --header "Authorization: Bearer $CLIMATIQ_API_KEY" \
  --data '{
    "product_name": "Bike frame",
    "location": "Phoenix, AZ",
    "description": "We are building 24 inch mountain bike frames from Steel for advanced mountain bikers.",
    "finished_product_weight": {
      "weight": 15.0,
      "weight_unit": "lb"
    }
  }'

Response

The response is equivalent (see the additions below) to that of the estimate endpoint with the fail_fast flag set to false.

This endpoint never generates use phase data, so use_phase is always null.

Top-level metadata

The top-level metadata of the returned product is always populated with two keys:

• created_via_screen_endpoint - always the string "true", so you can tell screened products apart from ones you created yourself
• user_provided_description - the description you sent in the request, or an empty string if you did not send one

{
    //...
    "metadata": {
        "created_via_screen_endpoint": "true",
        "user_provided_description": "We are building 24 inch mountain bike frames from Steel for advanced mountain bikers."
    }
}

Manufacturing inputs

In order to understand the manufacturing processes that the large language model added to the PCF, deviating from the normal response schema linked above, all manufacturing process items mirror the inputs that were used to create them. For example, an electricity process response could look like this:

{
    //...
    "manufacturing": {
        //...
        "breakdown": [
            {
                "type": "electricity",
                "total_co2e_kg": 0.195668243797,
                //...
                "inputs": {
                    "type": "electricity",
                    "amount": {
                        "energy": 0.15,
                        "energy_unit": "kWh"
                    }
                }
            }
        ]
    }
}

The inputs field mirrors the request schema of the estimate endpoint for manufacturing processes, with one exception: metadata is omitted from inputs, since it is already returned on the item itself.

Assumptions and reasoning

Every generated assumption comes with an explanation of how it was derived, so you can review, adjust, or reuse them in calculations.

These explanations are returned as keys of the metadata map on the manufacturing process or component they belong to. Like all metadata, the values are strings.

For manufacturing processes:

• process_name - a name for the process, to help understand what it represents
• confidence - how confident the model is in the process, eg. medium or low
• reasoning - an explanation of the process and/or a reasoning for it
• reasoning_fuel_type - why this fuel type was chosen (only for fuel combustion processes, absent on electricity processes)

For each component in the BoM:

• reasoning_location - why was this location chosen as the origin for the component
• reasoning_waste_ratio - explanation of the percentage of waste, e.g. via milling processes
• reasoning_weight - how the component weight was determined
• is_packaging_for_component - marks this component as being packaging for another component and refers to it by name (empty string on non-packaging components)

For example, a component in the returned bill of materials looks like this:

{
    //...
    "component": {
        "type": "simple",
        "product": "Main tubes (Steel)",
        //...
        "metadata": {
            "is_packaging_for_component": "",
            "reasoning_location": "Assuming procurement from high-quality steel tube manufacturers in Taiwan.",
            "reasoning_waste_ratio": "Estimated 10% material loss during cutting and mitering processes.",
            "reasoning_weight": "Standard 24 inch steel main triangle tube set weight."
        }
    }
}

Errors

In addition to the general error responses, this endpoint returns:

• 400 if the product_name is not recognizable as a manufacturable thing. The message explains why the product name was rejected.