Skip to main content

​
HERE EV Routing

EV routing is not car routing with a range filter bolted on. It is a routing problem where the vehicle’s energy state changes along the path, and where the route may require stopping to acquire more energy. That single difference — that the vehicle’s ability to continue depends on decisions made earlier in the route — is why you cannot approximate it by post-processing a car route against a charger database.

​
What problem this guide solves

You are routing a vehicle that can run out of energy in a way that a diesel truck effectively cannot, because refuelling infrastructure is dense and charging infrastructure is not, and because charging takes an hour rather than eight minutes. The system must answer: can this vehicle complete this route, where must it stop, and how long does the stop take.

​
Two distinct HERE products

Do not confuse these. They are different APIs with different entitlements.
EV routing is a capability within the Routing API. It accepts a consumption model and current charge state, and returns a route that may include charging stops. HERE EV Charge Points API is a separate product for finding and describing charging infrastructure — station locations, connector types, power feeds, availability, tariffs. It exists at v2 and v3, with a documented migration path between them. If you need a map of chargers, you want the EV Charge Points API. If you need a route that reaches its destination, you want EV routing. Most real products need both, and they bill separately.

​
When to use EV routing

  • Fleet dispatch where range is a binding constraint
  • Long-haul EV routing across sparse charging corridors
  • Range-anxiety features in driver-facing applications
  • Feasibility scoring before assigning an EV to a job
  • Electrifying an existing diesel route and needing to know whether it survives

​
When NOT to use it

  • Short urban routes well inside range. Standard routing is cheaper and simpler. If every job is 40 km and the vehicle has 300 km of range, charging is not a routing problem — it is a depot scheduling problem.
  • Displaying nearby chargers. That is the EV Charge Points API.
  • Charging session management or payment. Neither product does this.
  • Modelling total cost of ownership. Routing gives you energy consumption, not economics.

​
Key concepts

A consumption model is a curve, not a constant. Energy use varies with speed, gradient, and auxiliary load. A model that assumes linear consumption will be optimistic on highways and on hills. Charge state is an input, not an assumption. Routing from a vehicle at 22% charge produces a materially different route than the same vehicle at 90%. If your telematics feed provides live state of charge, use it. If it does not, be honest with the driver about what the ETA assumes. Charging stops are routing outputs. The engine may insert them. Your UI and your dispatch logic must handle a route with stops that the dispatcher did not request. Charger availability is a separate query and a separate freshness problem. A route computed against static charger data will confidently send a truck to an occupied or out-of-service charger. If availability matters, query it — and know that availability data has a latency that route computation does not. Truck charging is not car charging. HERE documents EV truck charging locations as a distinct concern within the EV Charge Points product. Connector types, power levels, and physical site access differ. A route computed against passenger-vehicle chargers is wrong for a Class 8 vehicle.

​
Code examples

EV routing parameters — consumption model, charge state, charging station preferences — are numerous, versioned, and mode-dependent. Rather than publish an example we cannot fully verify against your entitlement and API version, we link to HERE’s maintained reference and recommend confirming the current parameter set before implementation.Placematic will scope a working request against your actual vehicle profile and entitlement during a pilot. That is faster and safer than adapting a generic example.
The base routing endpoint and authentication are the same as standard routing — see Routing for the verified request shape and Authentication for key handling.

​
Production architecture

Vehicle energy profiles are model data. Battery capacity, consumption curve, connector type, and maximum charge rate belong on the vehicle record, not in the call site. This is the same argument as truck dimensions in Truck Routing, and it fails the same way when ignored. Separate feasibility from dispatch. Ask “can this vehicle do this job” as a cheap pre-check before you compute the full route with charging stops. Most rejections are obvious. Cache the network, not the availability. Charger locations change slowly. Availability changes by the minute. Different TTLs, different storage. Model the charging stop as a first-class event. Drivers need to know a stop is coming. Dispatchers need to know a vehicle is unavailable for 45 minutes. A route object that hides the stop inside a polyline will not survive contact with operations. Degrade honestly. If live charge state is unavailable, say the ETA assumes a full battery. Do not silently substitute an assumption.

​
Cost and usage considerations

EV routing bills as a routing transaction. The EV Charge Points API bills separately, under its own entitlement. Where teams overspend:
  • Querying charger availability on every route computation, when the route was cached
  • Recomputing full EV routes for feasibility checks that a range comparison would have rejected
  • Calling the Charge Points API per-map-pan rather than caching the network
Confirm entitlement for both products before you architect around them. A key that routes EVs may not query charge points. See Getting a HERE API Key.

​
Common mistakes

Approximating EV routing by filtering a car route against a charger table. The vehicle’s ability to reach charger three depends on whether it stopped at charger one. This is not a post-processing problem. Assuming full charge. Nearly every real dispatch begins at partial charge. Ignoring gradient and speed in the consumption model. Highway and mountain routes break linear assumptions. Routing a heavy commercial EV against passenger charging infrastructure. Different connectors, different power, different site access. Treating charger availability as static. A confidently routed truck arriving at an occupied charger is worse than no routing at all. Confusing EV routing with the EV Charge Points API. Separate products, separate entitlements, separate bills. Deploying against v2 of the Charge Points API without checking the v3 migration path.

​
Best practices

  • Store the full energy profile on the vehicle record
  • Use live state of charge where telematics provides it; disclose the assumption where it does not
  • Pre-filter infeasible jobs before computing full routes
  • Cache the charger network aggressively; cache availability barely
  • Surface charging stops explicitly in dispatch and driver UIs
  • Verify truck-specific charging data if you route commercial EVs
  • Confirm entitlement for both routing and charge points before you build

​
API reference

Routing

The base engine, request shape, and error semantics EV routing inherits.

Truck Routing

Physical constraints, which apply to electric trucks as much as diesel ones.

Matrix Routing

Matrix responses can include consumption alongside time and distance.

Choosing the Right HERE APIs

EV routing versus charge points — which question are you asking.
Also: HERE Pricing Explained · Getting a HERE API Key
Need production HERE API keys or implementation support? Placematic is an official HERE Technologies reseller and implementation partner helping companies choose the right HERE APIs, estimate usage, migrate from Google Maps and build production-ready geospatial solutions. Talk to us.