Sage X3 and the battery passport: integration pattern
How data from Sage X3 (Sage) 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
- Sage
- Deployments
- Cloud (Sage X3); On-premise (Sage X3)
- Checked
- not checked
- Managed integration
- —
Not checked: Sage names a GraphQL API; the reference is open to partners only. Clarify with the vendor before the project.
Interfaces
| Interface | Protocol | Sign-in | Events | Objects | Checked |
|---|---|---|---|---|---|
| GraphQL APIGraphQL API | GraphQL | OAuth 2.0 client credentials | none | Product/material master, Batch/serial number | not checked |
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.
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.