weclapp and the battery passport: integration pattern
How data from weclapp (weclapp) reaches the battery passport through the BatteryPass API: interfaces, workflows and when we checked them.
An integration pattern, not a ready-made connector: your ERP or integration platform reads and writes through the BatteryPass API with an organisation key. The details below come from the vendor documentation and were checked on the date given.
- Vendor
- weclapp
- Deployments
- Cloud (weclapp (REST API v1))
- Checked
- vendor documentation, 24 October 2026
- Managed integration
- —
The API token goes in the AuthenticationToken header; it belongs to a user, so create a technical user with narrow rights.
Interfaces
| Interface | Protocol | Sign-in | Events | Objects | Checked |
|---|---|---|---|---|---|
| REST APIArticles, serial numbers, shipments | REST | API key | none | Product/material master, Batch/serial number, Delivery/goods issue | checked in the vendor documentation, 24/10/2026 |
Matching workflows
Units from production
Serial numbers from the production confirmation or goods receipt are staged as an import; members review, commit and approve before any passport appears.
Passport links back into the ERP
The middleware follows the change feed and writes the GS1 Digital Link and the passport status to the serial number record in the ERP, so labels and delivery papers carry it.
Returns and repairs as lifecycle events
Completed repairs, inspections and component replacements from service or return orders appear as events in the unit's history.
Product change leads to a new model version
A change to the product master in the ERP triggers a notification; a member creates a new model version in BatteryPass. Declared data is never written automatically.
Import presets
- Generic CSV file: For any ERP and for files a middleware writes itself: GTIN, serial number, manufacturing date, facility (name or GLN), model version and battery status, with German and English column names.