Public API — Infrastructure Onboarding

How to register charging infrastructure — pools, stations, points, connectors — through the Public API so physical stations can connect over OCPP and start serving sessions.

The hierarchy

flowchart TD
    P["Charging pool<br/>(location: address, coordinates, timezone)"] --> S["Charging station<br/>(physical OCPP device, unique ocppId)"]
    S --> E["Charging point<br/>(EVSE, ocppId 1..n, eMI3 ID)"]
    E --> C["Connector<br/>(plug: standard, power type, tariff)"]

Every level is a separate resource with its own CRUD endpoints, but creation nests: a pool payload may embed stations, a station payload may embed points, a point payload may embed connectors. IDs at each level:

Prerequisites

• API key with the create permissions below (Authentication).
• A tariff — every connector requires a tariffId. List existing tariffs via GET /tariffs or create one first (tariff:create); see Tariffs & Pricing.
• Optionally an operatorId if the pool should belong to a specific CPO operator (defaults to your key's operator).

All endpoints below are relative to https://<host>/api/v1 unless noted, and return 200 with the created resource DTO (204 for delete).

Path A — one nested request

Onboard an entire site in a single POST /charging-pools:

curl -s -X POST \
  -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{
    "name": "Main Street Garage",
    "address": "Main Street 1",
    "city": "Berlin",
    "postalCode": "10115",
    "country": "DEU",
    "timezone": "Europe/Berlin",
    "latitude": 52.5321,
    "longitude": 13.3849,
    "chargingStations": [{
      "ocppId": "EWEL00629",
      "ocppPassword": "s3cret-commissioning-pw",
      "chargingPoints": [{
        "ocppId": 1,
        "eMI3Id": "DE*WAY*EWEL00629*01*1",
        "connectors": [{
          "ocppId": 1,
          "standard": "IEC_62196_T2",
          "powerType": "AC_3_PHASE",
          "format": "SOCKET",
          "voltage": 400,
          "amperage": 32,
          "tariffId": "<tariff-id>"
        }]
      }]
    }]
  }' \
  "https://<host>/api/v1/charging-pools"

The response is the full ChargingPoolDto including generated IDs for every nested resource — store them.

Required fields per level

Enum values (ConnectorType, ConnectorPowerTypeEnum, ConnectorFormatEnum, PoolFacility, …) are enumerated in the Swagger UI.

Path B — step by step

Same result, one level at a time. Child creation endpoints take the parent ID in the body:

# 1. Pool
curl -s -X POST -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{ "name": "Main Street Garage", "address": "...", ... }' \
  "https://<host>/api/v1/charging-pools"

# 2. Station → pool
curl -s -X POST -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{ "chargingPoolId": "<pool-id>", "ocppId": "EWEL00629" }' \
  "https://<host>/api/v1/charging-stations"

# 3. Point → station
curl -s -X POST -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{ "chargingStationId": "<station-id>", "ocppId": 1, "eMI3Id": "DE*WAY*EWEL00629*01*1" }' \
  "https://<host>/api/v1/charging-points"

# 4. Connector → point
curl -s -X POST -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{ "chargingPointId": "<point-id>", "ocppId": 1, "standard": "IEC_62196_T2",
        "powerType": "AC_3_PHASE", "format": "SOCKET", "voltage": 400, "amperage": 32,
        "tariffId": "<tariff-id>" }' \
  "https://<host>/api/v1/connectors"

Use this path when different teams own different levels, or when adding hardware to an existing site.

Path C — from a template

For fleets of identical hardware, define the point/connector structure once as a template and stamp out stations:

# Discover templates (note: no /api/v1 prefix on these two)
curl -s -H "x-api-key: $API_KEY" "https://<host>/charging-station-connector-config-templates"
curl -s -H "x-api-key: $API_KEY" "https://<host>/charging-station-ocpp-config-templates"

# Create a station from a template
curl -s -X POST -H "x-api-key: $API_KEY" -H "Content-Type: application/json" \
  -d '{
    "chargingPoolId": "<pool-id>",
    "chargingStationTemplateId": "<connector-config-template-id>",
    "serialNumber": "EWEL00629",
    "eMI3id": "DE*WAY*EWEL00629*01*01",
    "ocppKeysTemplateId": "<ocpp-config-template-id>"
  }' \
  "https://<host>/api/v1/charging-stations/from-template"

• serialNumber becomes both the station's ocppId and its internal serial number.
• The connector template defines the point/connector layout; eMI3id seeds the first point's EVSE ID and subsequent points increment its last two characters.
• ocppKeysTemplateId (optional) queues an OCPP configuration set to push once the station connects. It can also be passed in plain station creation (Paths A/B).

An existing station can also be duplicated within the same pool: POST /charging-stations/:id/copy.

Go-live lifecycle

flowchart LR
    A["Created<br/>(optionally exposeAsPlanned)"] -->|"physical station connects<br/>via OCPP (ocppId + password)"| B[Connected]
    B -->|"POST :id/publish"| C[Published / active]
    C -->|"POST :id/deactivate"| A2[Deactivated]
    A2 -->|"POST :id/publish"| C

1. Create the station in CPMS (any path above). Set exposeAsPlanned: true to advertise it to roaming/NAP feeds as planned before it's live.
2. Connect the hardware: configure the physical station to connect to your environment's OCPP endpoint with the exact ocppId (and ocppPassword if set). Verify the connection via GET /charging-stations/:id (connection status) or the OCPP log endpoints (charging-station:read-logs).
3. Publish: POST /charging-stations/:id/publish clears the planned flag and activates the station. POST /charging-stations/:id/deactivate reverses it.
4. Verify operational status via GET /business-status or connector status in GET /connectors.

Making changes later

• Updates are PUT /<resource>/:id; the body must carry the same id as the path or the request is rejected with 400.
• DELETE cascades downward: deleting a pool removes its stations, points, and connectors; deleting a point removes its connectors. Deletes are soft (resources disappear from the API) and irreversible through the API — there is no undelete endpoint.
• Move a station to a different pool with POST /charging-stations/:id/move-to-another-charging-pool (permission charging-station:move).
• Groups (/charging-pool-groups, /charging-station-groups, /charging-point-groups, /connector-groups) organize resources across the hierarchy; assign at creation via *GroupIds or manage via the group endpoints.

Related

• General guide — conventions, pagination, resource catalog
• Authentication — API keys, permissions
• Session Flows — what happens once the station is live