更新日志

Route matching

We have introduced Route Matching operations, allowing you to map-match external GPS traces and run them through our Routing Engine to calculate energy consumption and insert optimal charging stops.

• Calculate matched routes from coordinate sequences using the new createMatchedRoute mutation;
• Designate intermediate stopovers using vias defined by coordinate array index (via.index), with support for updating vehicle passenger counts and cargo weight dynamically along the journey;
• Enable plan_charging_stops: true to evaluate vehicle energy consumption along the pre-determined path and automatically insert compatible charging stops when needed;
• Query full CO₂ emissions profiles for completed matched routes using getRouteEmissions.

Improvements

• Updated the operator query to accept an external_id next to the internal id.

Fixes

• Fixed an issue where signing up to the dashboard with an email address containing uppercase letters prevented pending workspace invitations from being displayed upon login.
• Fixed a calculation and rounding discrepancy where the sum of leg section driving durations did not match total driving durations (durations.driving) in route details.

Subscriptions v2

We have launched a new subscription service hosted under a dedicated domain (subscription.chargetrip.io), delivering enhanced reliability, standard subprotocols, and new transport choices.

• Connect via WebSocket over wss://subscription.chargetrip.io/ws using the modern graphql-transport-ws protocol;
• Stream subscriptions over HTTP using Server-Sent Events via https://subscription.chargetrip.io/sse;
• Active subscription connections automatically close when a resource reaches its final state (such as done, error, or not_found for routes/isolines, and finished or error for navigation);
• Error payloads now follow consistent GraphQL error conventions with structured extensions metadata.

Station boosting groups on station queries

We extended station queries to provide visibility into whether a station belongs to an active boosting group.

• Added the boosting_group_ids field to the Station type across station, stationList, and stationAround queries;
• Returns an array of active boosting group IDs configured for your project, returning an empty list ([]) if the station is not currently boosted.

Fixes

• Fixed an issue where routes with multiple ferry connections could result in routes to arrive at charging stations with a negative State of Charge.
• Fixed an issue where calculating routes between origin and destination points located very close to each other produced an invalid line string error and failed with a 404 response.

Influence routes with Station Boosting

For businesses looking to maximize network utilization, honor partner agreements, or guide drivers to specific high-margin charging stations, Station Boosting offers a streamlined way to influence routing decisions. Available in Alpha, this feature gives you direct control over how specific charging locations are prioritized without adding unnecessary operational complexity.

• Targeted Client Groups: Create up to 5 distinct groups per environment (with up to 50 specific stations per group) to run targeted regional or time-based campaigns.

If you would like to test this feature and start steering volume to high-priority hardware, please reach out to your Customer Success Manager to manage your configuration.

Configurable maximum charging SoC & expanded battery limits

Drivers can now configure the maximum State of Charge (SoC) for charging stops between 80% and 100%, and plan trips requiring higher remaining battery levels upon arrival.

• Pass maximum_state_of_charge (80–100%) in createRoute (RouteVehicleChargingInput). When set, vehicles can charge beyond the default 80% ceiling during planned or unplanned stops across both ALWAYS_TO_MAX_CHARGE and OPTIMIZE_TRAVEL_TIME modes;
• Configure final_state_of_charge up to 80% of vehicle battery capacity (increased from 60%);
• Added two new SoC leg warnings: risk_margin_soc_not_possible when expected arrival SoC falls below the safety risk margin, and final_soc_below_risk_margin when the requested final SoC falls below the safe risk margin.

Improvements

• Added type and region array filters to vehicleMakes (VehicleMakesFilter), allowing clients to filter brands that offer specific vehicle types or operate within designated geographical regions.
• Added model_count to VehicleMake and vehicle_count to VehicleModel to expose real-time counts of accessible models per make and vehicles per model.
• Implemented cursor-based pagination arguments (first and after) along with total_count and page_info on the vehicleMakes query.
• Updated vehicleMakes and vehicle queries to return country-specific brand logos when a country filter is supplied, falling back to global images when localized assets are not configured.

Fixes

• Fixed an issue in vehicleList where filtering by make name failed after introducing make IDs, restoring backward compatibility so filter.make accepts both make IDs and make names.
• Fixed an issue where routes starting with an initial State of Charge below the safety risk margin (initialSOC < safeRiskMargin) drove until reaching 0% battery instead of routing to the nearest available charging station.
• Fixed an issue where the sum of individual leg section durations did not align with total driving durations (durations.driving) in route details.

Truck routing

We have officially launched our dedicated truck routing engine on the backend. Accessible via a brand-new set of queries and mutations, this standalone API feature factors in weight limits, height clearances, and truck-specific energy consumption models to build dependable commercial routes for heavy electric vehicles.

Improvements

• Improved validation and diagnostic error reporting when specifying via charging stations in createRoute, returning explicit error codes (ROUTE_STATION_OUT_OF_SERVICE, ROUTE_STATION_INVALID_CHARGER, and refined ROUTE_STATION_INVALID_SPEED) when charging is not possible, and introducing the via_station_below_minimum_power leg warning when available connectors fall below the requested minimum_power threshold.

Fixes

• Fixed an issue where total driving and trip durations (durations.driving and durations.total) on recommended and alternative routes omitted congestion delays when traffic_aware was enabled.
• Fixed an issue where routes ending at a charging station recorded an erroneous charging duration on the final leg and added an extra charge stop to the route’s total charges count.
• Fixed an issue where filtering vehicleList by make or model strings containing special characters (such as Lynk&Co, e.GO, ID.7, or N°4 E-Tense) returned empty results.
• Fixed an issue in amenityList where filtered POI search results did not match the station’s total amenity count.

Experimental and deprecation API warnings

We have introduced lifecycle warnings in GraphQL response extensions to inform developers whenever a requested operation or field is in alpha, beta, or scheduled for deprecation. This provides direct visibility into feature maturity and upcoming deprecations without disrupting API responses.

What’s new:

• Lifecycle notifications: Receive structured alerts under extensions.warnings whenever your request touches schema elements marked with @experimental(stage: "alpha"), @experimental(stage: "beta"), or @chargetripdeprecated;
• Consistent delivery: Warnings are included across all responses regardless of whether the operation succeeds or returns errors.

Improvements

• Extended createIsoline to support custom weather conditions (temperature, air_pressure, and solar_irradiance) alongside standard presets (summer, winter, actual) via the new weather input, deprecating the season input.
• Added station operating status warnings at the route leg level (station_closed, station_closing_soon, and station_unknown_open_hours) and refined station_limited_open_hours to warn drivers when a station on their route may be closed or have limited/unknown operating hours upon arrival.
• Standardized schema annotations by replacing hardcoded [BETA] text descriptions with the formal @experimental(stage: "beta") directive across the Isoline, Routing V2, and Navigation GraphQL schemas.

Fixes

• Fixed an issue in getRoute where savings.money returned null instead of 0 on BEV routes when no monetary savings were accrued.

Alternative routes

You can now request geographically different alternative routes alongside the recommended route during route calculation. This allows drivers and dispatchers to evaluate alternative paths based on their preferences while maintaining the same trip constraints. You can specify up to 2 alternative routes.

Fixes

• Fixed an issue where providing empty via waypoints without geometry, location, or station IDs in createRoute failed silently with a not_found status instead of returning a ROUTE_VIA_LOCATION_MISSING validation error.
• Fixed an issue in operatorList where queries using ranking filters returned empty results if the project had no excluded countries configured, ensuring operators matching ranking preferences are returned correctly.

Traffic

Enable traffic-aware routing for global traffic impact when calculating routes. Accounting for traffic and incidents while optimizing for charging has long been seen as the holy grail of EV route optimization. When enabled, the route response includes:

• Segments of the route affected by traffic;
• Level of congestion on those segments;
• Delay added to the total route duration.

This provides a more realistic estimate of travel time when traffic conditions affect the route and allows you to give globally optimized routes to your customers ready for turn-by-turn navigation.

Route warnings

Routing is often a best-effort process. Sometimes the routing engine cannot fully satisfy all requested conditions. Warnings help explain why a route may differ from the original request. Examples include:

• Unavailable operators: stations with preferred charging operators are not available for this route leg.
• Constraints: the requested final state of charge could not be achieved.

Warnings allow front-end teams to surface useful feedback to drivers or give engineers deeper insight into routing behavior. This makes it easier to understand routing results and troubleshoot edge cases.

Improvements

• Relaxed operator ranking validation in createRoute: if operator preferences (preferred or required) are requested without levels provided in the request or configured in project settings, route calculation now succeeds without operator prioritization and returns a non-breaking OPERATOR_PREFERENCES_NOT_FOUND warning in getRoute (also documented via /public/warnings).

Fixes

• Fixed an issue where searching or filtering the vehicle list (vehicleList) by strings containing parentheses (such as vehicle make or model names) caused query parsing failures and returned an internal server error.

Driving styles

Driving speed directly affects EV energy consumption. To make routes more accurately reflect real-world vehicle behavior and trip duration, we are introducing two new controls: speed factor and driving styles.

Driving styles change estimated arrival time and energy consumption.

• Eco assumes a more relaxed, efficient pace to save battery;
• Sport assumes higher speeds and greater consumption for a quicker arrival.

These features allow you to adjust routing calculations based on how a vehicle is actually driven, resulting in more precise consumption estimates and arrival times.

Updated getRouteStationsWithAmenities Schema

We updated the getRouteStationsWithAmenities query to simplify inputs and support multi-amenity filtering.

• Multi-amenity search: Query multiple amenity categories simultaneously with logical OR filtering;
• Direct time inputs: Pass time windows directly in seconds from the route origin;
• External station id: Access external_id on the station nodes.

Highway charging preference

This new option prioritizes chargers located on the highway, even in scenarios where off-highway stations may offer a faster route.

Fixes

• Fixed an issue where routes that retraced their path could end up with a negative state of charge.
• Fixed an issue where the charging time at the final stop was calculated incorrectly when using the OPTIMIZE_TRAVEL_TIME charging mode combined with a custom final state of charge.