APIs & Integration
Central API documentation and local Swagger
NeLeSo Developer documents API purpose, stability and product scope. Installed Gateway and Platform releases may expose version-specific OpenAPI specifications locally for approved services. The Developer Kit is not published yet; its contents and licence remain pending rights and security reviews.
Single Source
Versioned specifications for documentation and runtime.
For each published service contract, a versioned OpenAPI specification connects the central reference with the local Swagger UI. Customer domains, demo credentials and production-specific servers are not part of the public contract.
API catalogue
Different surfaces, clearly named contracts.
The matrix lists published and supported OpenAPI contracts. Internal or unversioned routes are not presented as public interfaces.
| API | OCPP Gateway | Charging Platform | Developer Kit |
|---|---|---|---|
| Gateway Control APIConnections · targets · routing | Not public | Product-internal | Not published |
| OCPP Server APIStations · state · commands | Not public | By release | Not published |
| CPMS Core APISessions · tokens · configuration | By release | ||
| Headless CPMS APIExternal integration surface | By release | ||
| Fleet & Driver APIsFleet · drivers · energy | By release |
Runtime Swagger
Local developer tooling deliberately remains.
The path may vary by installation. Local Swagger belongs to the installed, approved release; product, architecture and integration documentation remains central in NeLeSo Developer.
/api/docs/swagger-uiGateway services, OCPP Server and CPMS Core – on the respective service or installation proxy.
Open Sandbox CPMS Swagger →/api/docs/openapi.jsonRaw machine-readable specification for generators, tests and custom clients.
/docsHeadless CPMS currently uses this shorter Swagger path.
Open Sandbox Headless Swagger →Local Swagger UIs document the runtime contract. NeLeSo Developer remains the central source for architecture, products and integration.
API rules
Public API contracts follow four rules.
These rules apply to published, versioned APIs. Internal and unversioned routes are not public contracts.
Versioning
New public paths and schemas are assigned to a named API version.
Authentication
External APIs receive revocable keys or bearer tokens with scopes appropriate to the product.
Tenant boundaries
Where multi-tenancy applies, context is derived server-side from identity.
Deprecation
When a public contract is deprecated, it is named, tested and accompanied by a traceable migration path.