Connecting your ERP securely
How an ERP, its middleware and BatteryPass work together, who does what, and what never leaves your systems.
Your ERP knows products, serial numbers, production orders, deliveries and returns. BatteryPass holds the battery passports built from that data. This section shows how to connect the two so that data flows without anyone copying spreadsheets by hand, and so that declared passport data still enters BatteryPass only through a person in your organisation who stands behind it.
These pages describe integration patterns, not products: BatteryPass ships no ERP connector, holds no vendor certification and has no partnership with an ERP vendor. You build the connection with your middleware or iPaaS, on the published API.
The architecture
flowchart LR ERP["ERP<br/>(production, serials,<br/>deliveries, returns)"] -->|"outbox or event"| MW["Middleware / iPaaS"] MW -->|"API key, scope import:<br/>stage spreadsheet"| API["BatteryPass API"] MW -->|"API key, scope condition:<br/>measurements, events"| API API -->|"API key, scope read:<br/>change feed, passports, QR"| MW MW -->|"Digital Link, status"| ERP API --> PORTAL["Portal: members review,<br/>commit, approve"] PORTAL -->|"members publish"| PUB["Published passport<br/>(signed, public tier online)"]
- The ERP records what happens (a production confirmation, a goods receipt, a returned battery) and keeps the change in an outbox table or raises an event.
- The middleware (your own service or an iPaaS) collects the change, turns it into what BatteryPass expects and calls the API with a key of your organisation.
- BatteryPass checks every request against the key's scope, validates the data with the same rules as the portal and records every write in the audit log.
- Members of your organisation review in the portal: they commit staged imports, approve values and publish passports. Keys cannot do any of this.
- The middleware reads back what it needs (passport status, GS1 Digital Link, QR code) through the change feed and writes it to the ERP record.
Who does what
| Actor | Can | Cannot |
|---|---|---|
Key with scope import | Upload a CSV or XLSX file, map it (also with an import preset), validate it and read its result | Commit the import, approve values, publish |
Key with scope condition | Report measured condition data and lifecycle events | Change declared data such as capacity or chemistry |
Key with scope read | Read models, units, values, passports, exports and the change feed | Write anything |
| Editor (member) | Commit a validated import; the units are created as drafts | Approve values or publish |
| Reviewer, admin, owner (member) | Approve imported values, publish passports | Approve values they recorded themselves while the four-eyes rule is on; publish while required data is missing |
| Owner (member) | Create and revoke API keys in Settings → API keys |
The four-eyes rule is a setting of your organisation. Condition data reported with a key is stored as approved measurements without a reviewer; that is how measured data is meant to work (see Condition data and lifecycle).
What never flows
BatteryPass needs data about batteries, not about people. Keep these in your ERP:
- customer names, addresses, contact data and order numbers;
- names of employees, operators or service technicians;
- prices, margins and supplier conditions;
- vehicle, owner or location data of a battery in use.
A serial number is enough to link a passport, an event or a measurement to the record in your ERP. The security page explains data minimisation and the rest of the security model.
The five workflows
Units from production
Serial numbers become a staged import; members commit, approve and publish.
Passport links back into the ERP
Follow the change feed and store the Digital Link and status on the serial record.
Condition data from BMS and service
Report measurements with their time; older ones are skipped.
Returns and repairs
Completed service orders become lifecycle events, without customer data.
Product change
A product master change notifies a person, who creates a new model version.
Security model
Keys, scopes, retries, outbox, data minimisation and the OWASP API Top 10.
Middleware and standards
- iPaaS and middleware: n8n, Make, Power Automate, MuleSoft, Boomi, Workato, Zapier and SAP Integration Suite with a BatteryPass key, and how each polls the change feed.
- Standards: how BatteryPass data relates to DIN DKE SPEC 99100, the IDTA battery passport submodels and Catena-X.
ERP systems
The ERP registry lists, per system, the interfaces an integration can use, how they authenticate, whether they announce changes, and how and when we checked each fact. It is the same data the portal shows under Settings → Integrations.
| System | Vendor | Deployments | Checked |
|---|---|---|---|
| SAP S/4HANA Cloud Public Edition | SAP | Cloud | checked in the vendor documentation |
| SAP S/4HANA (on-premise and Private Edition) | SAP | On-premise | checked in the vendor documentation |
| SAP Business One | SAP | On-premise | checked in the vendor documentation |
| Microsoft Dynamics 365 Business Central | Microsoft | Cloud, On-premise | checked in the vendor documentation |
| Microsoft Dynamics NAV 2018 | Microsoft | On-premise | checked in the vendor documentation |
| Microsoft Dynamics 365 Finance and Supply Chain Management | Microsoft | Cloud | checked in the vendor documentation |
| Oracle NetSuite | Oracle | Cloud | checked in the vendor documentation |
| Oracle Fusion Cloud Supply Chain Management | Oracle | Cloud | checked in the vendor documentation |
| Odoo | Odoo S.A. | Cloud, On-premise | checked in the vendor documentation |
| Infor CloudSuite (M3, LN) | Infor | Cloud, On-premise | checked in the vendor documentationnot checked |
| IFS Cloud | IFS | Cloud, On-premise | community or marketing source only |
| Epicor Kinetic | Epicor | Cloud, On-premise | community or marketing source only |
| Sage X3 | Sage | Cloud, On-premise | not checked |
| abas ERP | abas Software (Forterro) | On-premise, Cloud | community or marketing source only |
| proALPHA ERP | proALPHA | On-premise | not checked |
| weclapp | weclapp | Cloud | checked in the vendor documentation |
| Xentral | Xentral ERP Software | Cloud | checked in the vendor documentation |
"Checked in the vendor documentation" means we read the vendor's public documentation on the date given. It is not a test against a live system and not an endorsement by the vendor. Entries marked "community or marketing source only" or "not checked" need confirmation in your project.