Module server 

Available on crate feature server only.

An OCPI server: one trait per module and interface, mounted onto an axum::Router.

use std::sync::Arc;
use ocpi_kit::server::{InMemoryTokenStore, OcpiRouter};
use ocpi_kit::types::Url;
use ocpi_kit::VersionNumber;

let tokens = Arc::new(InMemoryTokenStore::new());

let app = OcpiRouter::new(
        VersionNumber::V2_3_0,
        Url::new("https://cpo.example.com/ocpi/cpo/2.3.0")?,
        tokens,
    )
    .credentials(credentials)
    .locations_sender(locations)
    .build();

let listener = tokio::net::TcpListener::bind("0.0.0.0:8080").await?;
axum::serve(listener, app).await?;

What the router takes care of

• The status code rules. Only five situations get an HTTP error status; everything that reached the OCPI layer is a 200 OK with a four-digit code in the body. A handler returns OcpiError and the mapping happens once, correctly.
• Authentication, and the CREDENTIALS_TOKEN_A scope. A bootstrap token used on any module other than credentials and versions gets a 401, as the specification requires.
• Ownership of client-owned objects. A platform writing under a country_code/party_id that is not one of its own roles gets a 404 — “this way blocking client access to objects that do not belong to them” — and the handler is never called.
• X-Request-ID and X-Correlation-ID. Echoed on every response, generated when the peer forgot them.
• Version details. /versions and the version-details endpoint are generated from exactly what was mounted, so discovery cannot disagree with reality.
• The PATCH rule. A patch without last_updated never reaches a handler; it is the specification’s own example of a 2001.

What it deliberately leaves to you

Persistence, and the two credentials 405 rules — only the implementation knows whether a peer is already registered. PeerState has the predicates for those.

Structs

Auth

Extracts and authenticates the credentials token.

AuthenticatedPeer

The party a request was authenticated as.

CallbackUrls

Builds the response_urls that reach the callbacks this crate’s router mounts.

HttpStatusCode

Re-exported for handlers that build their own responses. An HTTP status code (status-code in RFC 9110 et al.).

Ids

The X-Request-ID and X-Correlation-ID of the request.

InMemoryTokenStore

A TokenStore held in memory, for tests, small deployments and getting started.

MountedModules

Which modules and interfaces this server implements, for generating version details.

OcpiErrorResponse

The HTTP response an OcpiError becomes.

OcpiJson

A JSON body, decoded with the path to any offending value.

OcpiPatch

A JSON Merge Patch body.

OcpiReply

An OCPI response on its way out: the envelope, plus the headers that must accompany it.

OcpiRouter

Builds the axum::Router that serves one OCPI version.

OcpiState

Everything the extractors and handlers share.

Owner

The {country_code}/{party_id} pair of a client-owned-object URL.

Page

The pagination query parameters.

PeerRegistry

A registry of the peers this server has registered, keyed by peer id.

RequestContext

The pieces of a request a handler is given.

Routing

The OCPI-to-* and OCPI-from-* headers, when present.

ServerConfig

How the server behaves.

Enums

Created

Whether a PUT created the object or replaced one.

Traits

AuthState

What Auth needs from the router’s state.

CdrsReceiver

The eMSP side of the CDRs module.

CdrsSender

The CPO side of the CDRs module.

ChargingProfilesReceiver

The CPO side of the Charging Profiles module: accepting profiles for a running session.

ChargingProfilesSender

The eMSP/SCSP side of the Charging Profiles module: receiving what the Charge Point decided.

CommandsReceiver

The CPO side of the Commands module: receiving commands from an eMSP.

CommandsSender

The eMSP side of the Commands module: receiving the asynchronous result.

ContentTypePolicy

What OcpiJson needs from the router’s state.

CredentialsHandler

The credentials module, which every implementation must serve.

HubClientInfoReceiver

The client side of the Hub Client Info module.

HubClientInfoSender

The hub side of the Hub Client Info module.

LocationsReceiver

The eMSP side of the Locations module: receiving the Locations another party owns.

LocationsSender

The CPO side of the Locations module: serving the Locations this party owns.

PagePolicy

What Page needs from the router’s state.

PaymentsReceiver

The CPO side of the Payments module: the PTP’s terminals as the CPO stores them.

PaymentsSender

The PTP side of the Payments module: the terminals this Payment Terminal Provider owns.

SessionsReceiver

The eMSP side of the Sessions module.

SessionsSender

The CPO side of the Sessions module.

TariffsReceiver

The eMSP side of the Tariffs module.

TariffsSender

The CPO side of the Tariffs module.

TokenStore

Resolves an incoming credentials token to the platform that holds it.

TokensReceiver

The CPO side of the Tokens module: receiving the Tokens an eMSP owns.

TokensSender

The eMSP side of the Tokens module: serving Tokens and answering real-time authorizations.

Functions

accepts_json

The default reading of the Content-Type rule.

echo_ids

Copies the request and correlation IDs onto a response, generating what is missing.

reject

Renders a rejection, so a handler can return one directly.

Type Aliases

Handled

The result every handler method returns.