A Digital Battery Passport (DBP) depends on information flowing between manufacturers, suppliers, service providers, recyclers and other authorised stakeholders. But how should these organisations exchange data securely and consistently across different systems?
Two approaches frequently discussed in this context are Application Programming Interfaces (APIs) and data spaces. Both support data exchange, but they address different requirements. APIs enable software applications to communicate, while data spaces provide a broader framework for governed data sharing between independent organisations.
As explored previously in our article about Digital Battery Passport integration architecture, choosing an appropriate technology stack involves more than connecting individual systems. It also requires decisions about interoperability, access permissions, data governance and the relationships between participating organisations.
This article compares APIs and data spaces, explains where each approach fits into a Battery Passport ecosystem, and considers how they can work together.
Understanding APIs in Battery Passport Data Exchange
An Application Programming Interface (API) is a defined interface that allows two software systems to exchange information or request services. It specifies how applications make requests, what data they can send or receive, and how responses are structured.
In a Battery Passport environment, APIs can connect internal business systems and external services. For example, a manufacturer's Enterprise Resource Planning (ERP) system may provide supplier and procurement information, while a Product Lifecycle Management (PLM) system supplies product specifications and engineering data. APIs can help transfer relevant information from these systems to a Battery Passport platform.
They can also support communication between the passport platform and external applications. An authorised recycler, for instance, could use an API to retrieve relevant battery composition or dismantling information, subject to the applicable access permissions.
Common API functions in this environment may include:
- Data retrieval: Requesting specific battery information from a connected system.
- Data submission: Sending validated information to a Battery Passport platform.
- Data updates: Communicating changes to battery status or other relevant records.
- System integration: Connecting enterprise applications, passport platforms and authorised third-party services.
APIs are particularly useful when organisations need predictable, structured communication between known systems. However, an API connection alone does not establish the wider rules for sharing data between independent organisations. Authentication and authorisation can control access to an interface, but questions about data ownership, permitted use, contractual obligations and governance require additional arrangements.
For a closer look at API-based exchange in the Battery Passport ecosystem, see Battery Passport APIs.
Understanding Data Spaces
A data space is a governed environment that enables different organisations to share and access data under agreed technical, organisational and legal conditions. Rather than simply connecting applications, it establishes a framework for trusted data exchange between independent participants.
A data space may include mechanisms for participant identification, data discovery, access control, usage policies, agreements and secure data transfer. These capabilities help organisations retain control over their data while making selected information available to authorised parties.
Consider a battery manufacturer that needs to share information with a recycling partner. The manufacturer may hold detailed battery composition and dismantling information, while the recycler needs access to specific records to plan its operations. A data space can provide a framework for identifying the participants, establishing the conditions for access and enabling the agreed information exchange.
Several elements are commonly associated with data spaces:
- Participant identification: Establishing the identity and credentials of organisations involved in data exchange.
- Data discovery: Helping participants find relevant datasets or data offerings.
- Access and usage policies: Defining who can access information and under what conditions.
- Agreements: Supporting the terms under which data is shared and used.
- Data exchange: Enabling information to move between participating organisations through supported technical mechanisms.
The Dataspace Protocol, developed through the Eclipse Dataspace Working Group, provides specifications for interactions such as publishing data offerings, negotiating agreements and accessing data. It supports the technical coordination of data exchange, but it does not independently define the meaning of every dataset or replace the governance arrangements required by participating organisations.
A data space is therefore not automatically secure or interoperable simply because an organisation joins one. Its effectiveness depends on suitable identity management, common data structures, agreed policies, technical standards and governance.
APIs vs Data Spaces: Key Differences
Although APIs and data spaces can both facilitate data exchange, their purposes and scope differ.
Consideration | APIs | Data Spaces |
Primary purpose | Enable communication between software systems | Enable governed data sharing between organisations |
Main focus | Interfaces, requests, responses and data transfer | Participants, trust, governance, agreements and data access |
Typical participants | Applications and services | Independent organisations and their systems |
Access management | Often handled through authentication and authorisation mechanisms | Can include participant identity, credentials, access policies and agreements |
Data discovery | Usually defined through documentation or application-specific mechanisms | Can support discovery of data offerings across participants |
Data usage conditions | May be addressed through separate contracts and policies | Can incorporate agreed usage conditions into the data-sharing framework |
Typical application | Connecting ERP, PLM, MES and passport platforms | Sharing selected information across manufacturers, suppliers, recyclers and other stakeholders |
The distinction is important when designing a Battery Passport ecosystem. An API can provide the technical connection through which data is exchanged, but it does not necessarily provide the governance framework for a multi-party data-sharing relationship. A data space addresses a wider set of requirements, while still relying on technical interfaces and data-transfer mechanisms.
Neither approach automatically guarantees data quality, semantic interoperability or regulatory compliance. These depend on the underlying data models, validation processes, standards and governance arrangements.
How APIs and Data Spaces Can Work Together
For many Battery Passport implementations, the most practical approach may be to combine APIs and data spaces rather than choose one over the other.
A hybrid architecture can use APIs for communication between an organisation's internal systems and its Battery Passport platform, while a data space provides the framework for sharing selected information with external participants.
For example, consider a battery manufacturer preparing information for its Battery Passport:
- Collecting internal data: APIs connect the manufacturer's ERP, PLM, Manufacturing Execution System (MES) and other relevant applications to the passport platform.
- Processing and validating information: The platform checks incoming records against the required data structures, business rules and quality requirements.
- Preparing data for sharing: The manufacturer identifies which information can be shared with particular stakeholders and defines the applicable access conditions.
- Sharing through a data space: The data space helps establish participant identity, discover relevant data offerings and manage the agreed conditions for access.
- Integrating received information: An authorised recipient can use APIs or other supported interfaces to bring the information into its own applications.
This arrangement allows organisations to maintain their existing software integrations while participating in a wider data-sharing ecosystem. It can also support different levels of access for different stakeholders, rather than requiring every participant to receive the same information.
The approach depends on clear data governance. Organisations need to establish who is responsible for maintaining records, who can approve updates and which stakeholders are entitled to access particular information. These questions are closely connected to Battery Passport data governance and access permissions across the Battery Passport ecosystem.
What Does the EU Battery Regulation Require?
The EU Batteries Regulation (EU) 2023/1542 sets out technical and operational requirements for the Digital Battery Passport.
Under Article 77, from 18 February 2027, relevant electric vehicle batteries, light means of transport batteries and industrial batteries with a capacity greater than 2 kWh placed on the EU market or put into service must have a Battery Passport.
Article 77 also requires passport information to be based on open standards and provided in interoperable formats. It must be transferable through an open interoperable data exchange network without vendor lock-in, and be machine-readable, structured and searchable.
Article 78 adds requirements concerning interoperability, data access rights, authentication, reliability, integrity, security and privacy. It also requires interoperability with other Digital Product Passports established under EU ecodesign legislation.
Importantly, the Regulation does not prescribe a single architecture in which all Battery Passport data must be exchanged through APIs or a particular data-space framework. Organisations have room to select appropriate technologies, provided their solutions meet the applicable regulatory requirements.
This makes standards and data models particularly important. Technical interfaces must exchange information in formats that participating systems can interpret consistently. Organisations should therefore consider relevant interoperability standards and the work of CEN-CENELEC JTC 24 when designing their solutions. Our article on JTC 24 standards and interoperability provides further context.
Key Considerations When Choosing an Approach
The right architecture depends on an organisation's systems, partners, data-sharing requirements and implementation priorities. Before selecting an approach, Battery Passport teams should consider:
1. Existing IT infrastructure: Identify the systems that already hold relevant battery information and determine how they can be connected. APIs may be suitable for integrating established enterprise applications.
2. Number and type of external participants: If information needs to be shared across a network of independent organisations, a data-space framework may help manage participant relationships and agreed access conditions.
3. Data ownership and access rights: Establish who controls the information, who can access it and for what purposes. Commercially sensitive and restricted information requires appropriate safeguards.
4. Interoperability and standards: Ensure that systems use compatible data structures, identifiers and exchange formats. Technical connectivity alone does not guarantee that information will be interpreted consistently.
5. Flexibility and vendor independence: Avoid architectures that make it difficult to change service providers or connect to other systems. Open standards and clearly documented interfaces can help reduce dependency on individual technology providers. Organisations evaluating solutions can also consult guidance on choosing a Battery Passport platform without vendor lock-in.
How BASE Approaches Battery Passport Data Exchange
The BASE project, Battery Passport for Resilient Supply Chain and Implementation of Circular Economy, is working towards a trusted and interoperable Digital Battery Passport framework. Data exchange is an important part of this work because battery information needs to move across different systems, organisations and stages of the battery lifecycle.
By examining the technical and organisational requirements of Battery Passport implementation, BASE contributes to the development and validation of approaches that support traceability, secure information sharing and interoperability. The choice between APIs and data spaces is therefore best understood in the context of the wider architecture, governance model and requirements of the organisations involved.
Closing Thoughts
APIs and data spaces address different aspects of Battery Passport data exchange. APIs provide the interfaces that connect applications and transfer information, while data spaces establish a broader framework for trusted and governed sharing between organisations.
For many implementations, combining the two may offer a practical way forward. APIs can connect internal systems and services, while data spaces can support controlled collaboration across supply-chain participants. Ultimately, the effectiveness of either approach depends on sound data governance, common standards, reliable information and compliance with the Battery Passport's technical requirements.
The BASE project has received funding from the Horizon Europe Framework Programme (HORIZON) Research and Innovation Actions under grant agreement No. 101157200.
References & Resources
European Union - Regulation (EU) 2023/1542 Concerning Batteries and Waste Batteries: https://eur-lex.europa.eu/eli/reg/2023/1542/oj
European Commission - EU Digital Product Passport FAQ for Batteries: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/eu-digital-product-passport-faq-batteries_en
European Commission - Digital Product Passport for Batteries: https://single-market-economy.ec.europa.eu/single-market/digital-product-passport/batteries_en
Eclipse - Dataspace Protocol 2025-1: https://eclipse-dataspace-protocol-base.github.io/DataspaceProtocol/2025-1-err2/
International Data Spaces Association - Introduction to data spaces: https://kb.internationaldataspaces.org/dataspace/