GridOS is an OCPI gateway for CPO and eMSP roaming: credentials, tokens, locations, sessions, tariffs, and CDRs across OCPI 2.1.1, 2.2.1, and 2.3.0 without bolting partner logic into your core product.
Best for
Operators launching or stabilizing OCPI roaming who need a dedicated OCPI gateway rather than ad-hoc partner scripts.
Audience
CPO roaming teams, eMSP platform leads, and interoperability owners.
How to use this page
Read this as an architecture page, not only a feature page.
The key question is how to stabilize charger connectivity while backend, roaming, or reporting systems change underneath.
Use the outcomes and pain points to decide whether this is a migration problem, a roaming problem, or a longer-term control-layer problem.
Why this solution exists
An OCPI gateway is the operator-facing control plane for roaming partners and hubs. Buyers looking for OCPI gateway software need production module coverage, partner onboarding, and clean separation from charger OCPP traffic. GridOS provides that OCPI gateway layer alongside the OCPP gateway.
Partner onboarding stalls on unclear OCPI module scope and credentials.
Token, session, tariff, and CDR behavior diverges across partners and hubs.
Roaming logic is hard-coded into the CPMS, so every partner becomes a release risk.
OCPP charger ops and OCPI partner ops share no clean operational boundary.
CDR and billing disputes lack a single source of truth for exchange status.
What the team gets
OCPI gateway for bilateral and hub-style partner connections.
Clearer credentials, versions, and module ownership per partner.
Session and CDR flows that ops can monitor without diving into raw dumps only.
Separation between OCPP charger control and OCPI roaming exchange.
Faster path from pilot partner to production roaming.
Move from use case into rollout or product evaluation
Qualify fit quickly. Start in GridOS to test the product path, or talk to the team if migration, roaming, or multi-backend coexistence needs scoping first.