How to give customers battery passport data they can use

Customers can only use battery passport data if we give them the right information, in a form they can actually work with, and with enough context to trust what they are seeing. The practical question is not whether we can expose passport data. It is how we package it so a procurement team, OEM, distributor, recycler, repair network, or regulator-facing customer can find the fields they need without being buried in internal detail.

When people ask us how to share battery passport data with customers, our answer is consistent. Start from the customer’s use case, separate customer-facing data from internal records, choose an access method that matches how often the data will be used, and put governance around updates and permissions from day one. If we do that well, the passport becomes useful evidence, not just a compliance file.

Customers rarely want the entire underlying data model. They want the subset that helps them buy, install, operate, maintain, resell, repurpose, or recycle a battery product with confidence.

That usually starts with clear product identification. At a minimum, we should make sure customers can see the battery model, relevant serial or unique identifier, manufacturer details where appropriate, production date or batch reference, chemistry, rated capacity, and intended application category. If a customer cannot tell exactly which physical battery or battery lot the record relates to, the rest of the passport has limited value.

The next layer is performance and compliance information. Depending on the product and market, customers may need to check declared capacity, expected service conditions, safety-related handling information, conformity-related references, and end-of-life instructions. They may also need carbon footprint information, recycled content declarations, or sourcing-related disclosures where those are part of the passport scope or a contractual requirement.

Use case changes everything. A procurement team comparing suppliers needs standardised, comparable fields. A repair workshop needs service-relevant data, replacement compatibility, and handling instructions. A recycler needs composition, disassembly, hazardous fraction information, and treatment guidance. A large OEM customer may also need machine-readable identifiers so they can connect our battery passport records to their own ERP, PLM, MES, or asset management systems.

This is why we should not treat customer sharing as a single export for everyone. We need audience-based views.

For example:

• A distributor may need product identity, transport classification, storage guidance, and warranty-relevant traceability.
• An industrial end user may need installation constraints, operating limits, maintenance intervals, and current passport status.
• A repair network may need component-level references, safe handling instructions, and version history when a product configuration changes.
• A recycler may need material composition, dismantling information, and treatment pathways.
• A compliance or sustainability team may need evidence fields that support declarations already made in contracts or tenders.

We should also think about what customers need to do with the data after they receive it. Some will only read it. Others will import it into systems, compare it across suppliers, or use it as evidence in audits. That affects not only which fields we share, but how structured those fields need to be.

If we are still building our data foundation, it helps to start with the records that are most likely to be requested repeatedly. Our guide to what data a battery passport needs is a useful starting point for deciding which fields belong in that baseline.

Before we publish or send any passport information, we need a clear data classification step. This is where many projects go wrong. Teams assume transparency means exposing everything collected internally. It does not.

A practical way to structure this is to divide data into four categories.

First, customer-essential data. This is the information a customer genuinely needs to identify the battery, verify claims, use the product correctly, and meet downstream obligations. This category typically includes unique identifiers, core technical specifications, declared compliance-related attributes, handling guidance, and end-of-life information.

Second, customer-useful but conditional data. This may include deeper traceability fields, selected supply chain information, repair-relevant data, or sustainability metrics that are helpful for some customers but not all. We may share these fields only with specific customer groups, under contract, or through authenticated access.

Third, internal-only data. This covers process parameters, quality control notes, internal non-conformance records, supplier pricing, proprietary formulations, commercially sensitive sourcing details, and internal risk assessments. These records may support the passport internally, but they are not automatically customer-facing.

Fourth, restricted data. This includes personal data, export-controlled information where relevant, information protected by contractual confidentiality, and security-sensitive details that could create misuse risk if disclosed too broadly.

Once we have these categories, we should map each field in the passport dataset against three questions:

1. What customer task does this field support?
2. Is there a legal, contractual, or operational reason to share it?
3. Is there a legal, commercial, or security reason not to share it openly?

If we cannot answer the first question, the field probably should not be in the customer-facing view.

This is also the point where we should define our level of granularity. Customers often need evidence of traceability, but not every underlying transaction. For example, they may need confirmation of material origin category or due diligence status, without seeing supplier-by-supplier commercial detail. They may need a declaration of recycled content and the method used, without access to internal calculations or negotiation records.

In the EU context, battery passport obligations are developing within a broader regulatory framework, and the exact implementation details may depend on battery category, delegated acts, and the technical systems used to support compliance. Where a country applies additional national requirements around waste handling, market surveillance, or data access, we need to account for those too. In practice, that means our customer dataset should be aligned first to EU-level battery traceability and passport requirements, then checked against any country-specific obligations in the markets where the battery is placed on the market or serviced.

We should also separate evidence from explanation. A customer-facing passport works better when the main data view stays concise, while supporting documents sit behind links or attachments. That lets us keep the primary record structured and readable.

If our traceability data is still fragmented across suppliers, plants, spreadsheets, and quality systems, it is worth fixing that before designing the customer view. Our article on how to organise battery traceability data without gaps sets out the operational groundwork.

The best delivery method depends on how the customer will use the data, how often it changes, and how much control we need over access.

For one-off or low-frequency sharing, a secure portal is usually the most practical option. A portal gives customers a single place to search by serial number, batch, or product code, view the current passport record, and download supporting documents. It also lets us manage permissions centrally and update the live record without sending revised files around by email.

Downloadable files work well when customers need offline access or want to import data manually into procurement or compliance workflows. The key is to choose a format that matches the task. PDF is useful for human-readable summaries and evidence packs. CSV or XLSX is better for tabular comparison and internal processing. JSON or XML is better where the customer wants structured machine-readable data.

APIs are the right choice when customers need regular, automated access at scale. If a customer is integrating battery passport records into an ERP, digital product passport platform, service system, or sustainability reporting workflow, an API avoids repeated manual exports and reduces version confusion. APIs also make it easier to provide only the fields each customer is authorised to access.

Document links are helpful, but they should support the passport, not replace it. A customer should not have to open six separate files to answer basic questions about a battery. We should present core passport fields directly, then link out to declarations, test summaries, manuals, dismantling instructions, or certificates where more detail is needed.

In practice, a layered model works best:

• A web view for quick human access
• A downloadable summary for audit and procurement use
• Structured data export or API for system-to-system exchange
• Linked supporting documents for evidence

We should also think about identifiers and discoverability. If the passport is accessed through a QR code, unique identifier, or serial lookup, the user journey must be simple. The identifier printed on the battery, packaging, or product documentation should match the identifier used in the portal or API. If customers need to guess which reference to enter, support tickets will follow.

For customers in heavily regulated or technically mature environments, APIs often become the preferred route over time. For smaller customers, a portal and downloadable evidence pack may be enough. There is no value in forcing every customer into an integration model they will not use.

If your main challenge is understanding the regulatory backdrop before choosing a delivery method, our overview of EU battery traceability rules without the compliance guesswork is a good companion piece.

Transparency and control have to coexist. Customers need confidence that the passport is real, current, and complete for their purpose. We need confidence that we are not exposing confidential, personal, or security-sensitive information by mistake.

The first control is role-based access. Not every customer should see the same data. A public-facing view may contain basic identification and high-level sustainability information. An authenticated customer account may unlock operational and compliance fields relevant to purchased products. A repair partner or recycler may receive a different view again, based on their role and contractual relationship with us.

The second control is data minimisation. If a field is not needed for the customer’s task, we should not expose it. This matters especially for personal data. If passport-related records contain names, direct contact details, signatures, or user-level logs, we need to assess whether those elements are necessary to share at all. In many cases they are not.

The third control is confidentiality by design. We should define which fields are commercially sensitive before any publication workflow begins. Supplier identities, exact sourcing routes, proprietary bill-of-material details, and plant-level process settings are common examples. Sometimes customers need assurance that due diligence has been performed. That does not always mean they need the underlying confidential record.

The fourth control is a full audit trail. We should log who published a record, when it was changed, which source systems fed it, and which customer accessed or downloaded it where appropriate. This protects us in disputes and helps demonstrate control during audits.

The fifth control is document governance. Supporting files linked from the passport should be approved versions only, with clear status labels such as current, superseded, or withdrawn. Broken links, duplicate files, and uncontrolled local uploads quickly undermine trust.

In an EU setting, we also need to align with data protection obligations where any personal data is involved, and with contractual confidentiality obligations across the supply chain. National enforcement approach can vary by country, even where the baseline legal framework is EU-wide, so our internal review process should include legal and compliance checks for the jurisdictions where we operate.

A practical approval workflow often includes:

• Data owner review for technical correctness
• Compliance review for mandatory fields and restricted content
• Legal review for confidentiality and personal data risks
• Final publication approval with timestamp and version number

If security and compliance are slowing down your passport rollout, our guide to data security compliance without the jargon sets out the controls in plain operational terms.

Sharing the data is only the start. A battery passport that goes stale is worse than one that is unavailable, because customers may rely on outdated information without realising it.

We need a defined maintenance process from the outset. That means deciding which fields are static and which are dynamic.

Static fields usually include product model, initial chemistry classification, original manufacturing references, and baseline design data. Dynamic fields may include status updates, revised declarations, service notices, repair-related compatibility information, or corrected traceability links after an internal investigation.

Every passport record should have a version number or revision identifier, a publication date, and where relevant a last updated date. Customers should be able to tell whether they are looking at the latest approved version without comparing files manually.

Change control matters just as much. We should define what counts as a major change and what counts as a minor correction. For example:

• A corrected spelling error in a non-critical field may only need silent revision logging.
• A change to material composition, safety handling, or end-of-life treatment information should trigger customer notification.
• A revised compliance-related declaration should trigger both a new version and a clear notice to affected customers.

Notifications should be proportionate to the impact. For high-impact changes, email alerts or portal notifications to named customer contacts are appropriate. For lower-impact changes, an updated change log within the portal may be enough.

We also need source-system discipline. If passport data is assembled from ERP, MES, PLM, laboratory systems, supplier declarations, and manual uploads, someone must own reconciliation. Otherwise the customer-facing view drifts away from the operational truth. We should assign field-level ownership, with named teams responsible for maintaining each data domain.

Customer support is part of data quality too. When a customer spots an inconsistency, there should be a clear route to raise it. A good process includes:

• A contact point for passport-related queries
• A ticket category specifically for data issues
• Internal service levels for review and correction
• A documented root cause process where errors are confirmed
• A method for notifying affected customers after correction

Finally, we should review usage. Which fields are customers actually opening, downloading, or querying through the API? Which questions still arrive by email despite the passport being available? Those patterns tell us whether the shared dataset is useful or whether we are still making customers work too hard.

The most effective answer to how to share battery passport data with customers is not a single file format or a compliance checklist. It is an operating model. We define the customer use case, publish only the right data, deliver it in a usable format, protect what must stay controlled, and maintain the record over time. When we do that, the battery passport becomes part of how customers buy and manage batteries, not just another obligation sitting beside the product.