Common APIs
Services across the group speak a single, versioned interface contract defined schema-first and generated into every language the group uses. It is the reason a team in one company can call a service in another without a meeting, and the reason a breaking change is caught in CI rather than in production.
Inside the platform
Schema-first definitions
The interface is the source of truth; clients and servers are generated from it, in Go, TypeScript and Rust alike.
Versioning & compatibility
Compatibility checked in the pipeline, so an incompatible change fails the build rather than a customer.
Auth & identity conventions
One authentication and authorisation model across services, rather than a per-team interpretation of it.
Generated clients
No hand-written HTTP glue, and no drift between what a service promises and what a client expects.
The shape of the work
How we structure a line-of-business platform
Clients talk to one authenticated API surface; domain services own their data and publish events, so integrating an ERP or MES never means reaching into another service's database.
Used across the group
- Every service the group runs
Ownership
A shared platform. It has no natural home in any single unit, so the group funds it centrally and the shared engineering bench maintains it. Every company and division draws on the same version.
How we decide what is sharedOther platforms
Firmware SDK
The common embedded foundation — hardware abstraction, drivers, secure boot and update, with timing you can reason about.
Read moreDevice Management
Fleet identity, provisioning and health — knowing what is deployed, where, running what.
Read moreOTA Platform
Staged, reversible firmware campaigns across a fleet — the return path designed at the same time as the forward one.
Read moreBuilding something that needs Common APIs?
Tell us the constraints and we will come back with how this platform would carry them — or say plainly if it would not.