Fleet Management Endpoints

The Fleet Management API groups together three concerns that arise when operating a fleet of electric vehicles:

1. Fleet Badge Management — register and resolve RFID badges within a fleet namespace
2. Vehicle Identification (Assumed Vehicle) — map an EVSE or a badge to the vehicle likely connected when direct identification is unavailable
3. Charging Requirements — express per-vehicle charging needs so Dreev can schedule charging optimally

Fleet Badge Management

A fleet badge is an RFID badge scoped to a fleet. The same physical badge UID can mean different things in different fleets, avoiding conflicts across operators.

Badges can be created, updated, and deleted within a fleet namespace via /fleets/{fleetId}/badges/{badgeId}.

Vehicle Identification — Assumed Vehicle

When an EVSE cannot identify the connected vehicle through native protocols (e.g. ISO 15118 / Plug & Charge), Dreev falls back to assumed vehicle resolution. An assumed vehicle can be configured at two levels:

• EVSE-level (/evses/{evseId}/assumed-vehicle) — a static default vehicle assigned to a specific EVSE, regardless of who plugs in.
• Fleet badge-level (/fleets/{fleetId}/badges/{badgeId}/assumed-vehicle) — a vehicle associated with a specific badge within a fleet namespace. When a driver taps their badge at an EVSE, Dreev can resolve which vehicle they are likely driving.

Resolution logic

GET /evses/{evseId}/assumed-vehicle is the resolution endpoint used both by partners and internally by Dreev when processing a transaction. It works as follows:

• With badgeId — Dreev performs fleet-scoped badge resolution: it collects all fleets linked to the EVSE (an EVSE can belong to multiple fleets via EVSE groups), then for each fleet looks up the (fleetId, badgeId) → vehicle association, and returns the first match found in fleet precedence order.
• Without badgeId — Dreev returns the statically configured assumed vehicle for that EVSE, if any.

The inverse lookup /vehicles/{vehicleId}/assumed-evses returns all EVSEs where a given vehicle is the statically configured assumed vehicle.

Charging Requirements

Charging requirements tell Dreev what a vehicle needs by a given deadline. Dreev factors these constraints into its optimal charging schedule.

There are multiple requirement types:

• SoC requirements — express a target State of Charge (e.g. "80% by 7am"). Use these when the vehicle reports SoC and you want to guarantee a specific battery level.
• Energy requirements — express a top-up energy quantity (e.g. "add 20 kWh by 7am"). Use these when SoC telemetry is unavailable and you can only reason about energy delivered.
• Instant Charge (a.k.a. Emergency charge, Priority charging, Boost) — switches an active transaction to charge as fast as possible via PUT /transactions/{transactionId}/transaction-mode. This reduces the benefits of smart charging. Electrical installation constraints still apply, so the commanded power may be lower than the vehicle's maximum.
• Trips — declare an upcoming vehicle departure with a precise exit time and the energy needed for the journey. Unlike SoC or energy requirements, a trip tells Dreev that the vehicle will unplug at a given time, so Dreev anticipates the end of the transaction and ensures the required energy is delivered before departure. Each trip specifies a departure instant, an arrival instant, and the energy (Wh) needed.

SoC and energy requirements support one-time and recurring modes:

Individual requirements can be fetched or deleted by ID (/one-time-soc-requirements/{id}, /recurring-energy-requirements/{id}, etc.).

SoC Schedule (read-only)

Three additional endpoints let you inspect the resolved SoC constraint schedule that Dreev will use for optimisation:

• /vehicles/{vehicleId}/soc-requirements — the effective SoC requirement at a specific instant
• /vehicles/{vehicleId}/soc-requirements/next — the next upcoming SoC requirement
• /vehicles/{vehicleId}/soc-requirements-schedules — a.k.a. Lance's Curve™️. The full schedule over a time window

Trips

Legacy/trips batch endpoint (deprecated)

Registers or replaces trips for a list of vehicles over a given time period.

The client provides the period and an explicit list of vehicles with their trips. For each vehicle, all existing trips within the period are deleted and replaced with the provided ones.
Trips outside the period are left untouched, making the operation a targeted overwrite rather than a full replacement.

Vehicle IDs are expressed using the CSMS's own identifier space and resolved internally by Dreev. Unknown vehicle IDs are reported as errors in the response. Errors are per-vehicle — a
failure on one vehicle does not prevent other vehicles from being processed.