What is Pickler’s API for?

Pickler’s API is built for companies that already manage product data in an ERP, PIM, PLM, webshop or internal database. Instead of re-entering product information manually, your team can send structured product data to Pickler and retrieve product and footprint data back for reporting, product passports, comparisons and customer-facing workflows.

The API is a REST HTTP API. Developers can authenticate with a bearer token, create new products, update existing products, delete products, find products by ID and retrieve IDEMAT reference values for production and transport setup. This makes it flexible enough for a simple first sync, but also scalable enough for a more automated product data pipeline.

Why this matters for product footprint data

Product footprint data only becomes useful at scale when it stays connected to the systems where product data already lives. Many teams have hundreds or thousands of products with changing materials, suppliers, categories, weights, transport routes or internal IDs. Copying that data between tools creates extra work and makes it harder to keep customer answers up to date.

With an API connection, Pickler can become the footprint layer on top of your existing product data. Your system keeps managing the commercial and operational product fields. Pickler structures the sustainability fields and calculates the environmental impact, so the same product data can feed product passports, impact widgets, exports, reporting and customer requests.

How easy is it to set up?

The JSON structure is straightforward for developers. A product is sent inside a products array. Core fields such as name, status, category, internal product ID, description and scenario status sit at product level. Materials, production location, transport and end-of-life can be added in structured blocks.

A useful detail is the use of referenceName. Your developers can send names such as a category, material, location or region. Pickler can then map those references in the platform. This avoids needing every value to be perfectly matched before the first API test and makes the integration easier to phase in.

Authorization: Bearer <token>
POST /api/products

{
"products": [
{
"name": "Paper cup 4 oz",
"status": "draft",
"isScenarioProduct": false,
"category": {
"referenceName": "Cups"
},
"description": "Hot drink paper cup with inner barrier coating",
"internal": {
"productId": "SKU-123",
"supplierArticleId": "2003173"
},
"components": [
{
"type": "base",
"componentName": "Cup",
"materials": [
{
"referenceName": "Brown paper",
"weight": 3.2,
"location": {
"referenceName": "Europe"
}
},
{
"referenceName": "LDPE",
"weight": 0.18,
"location": {
"referenceName": "Europe"
}
}
],
"location": {
"referenceName": "Poland"
}
}
],
"eol": {
"regions": [
{
"referenceName": "Europe",
"share": 1
}
]
}
}
]
}

Start simple, then expand

The best first version is usually small: sync a limited set of product IDs, names, categories, materials, weights and end-of-life regions. Once that works, you can add more detail such as transport, production methods, energy use, compliance fields, sharing settings or more complete component structures.

This approach keeps implementation realistic. You do not need a fully custom ERP connector before getting value. A developer can start with a direct API sync, validate the mapped fields in Pickler and then expand the data flow as product footprint use cases become more mature.