Most teams budget for “maps” as a single line item. Then someone asks for turn-by-turn navigation inside the driver app, and the model quietly stops working.
This is not a pricing problem. It is an architecture problem that shows up on an invoice.
The teams that get burned are rarely careless. They scoped a mapping feature correctly, priced it against a published rate card, and shipped. What broke was the assumption that every location capability bills the same way. It does not, and the gap between the two models is where budgets go missing.
A request-based Maps API bills you when your backend asks a question. Geocode this address. Calculate this route. Build this matrix. One question, one charge. It is predictable, easy to cap, easy to forecast, and easy to cache.
Turn-by-turn navigation does not ask one question.
A driver running a 400-mile lane recalculates around a closure, reroutes after a missed exit, keeps the map rendering for six hours, and loses signal twice crossing rural Nebraska. That is not a sequence of questions. It is continuous behavior on a device you do not control, in conditions you cannot predict.
If you build it on metered request APIs, two things happen. Your cost stops correlating with revenue and starts correlating with driver behavior — a bad month of detours becomes a bad month of margin. And your app fails in exactly the places where drivers most need it to work: tunnels, dead zones, remote yards, and the last mile of a distribution center where coverage drops to one bar.
Two cost models: a backend asking discrete questions, and a device running a continuous session.
Google Maps Platform replaced its single shared monthly credit with separate free usage caps assigned per SKU, split across Essentials, Pro, and Enterprise tiers. The enrollment window for fixed-price subscription plans closed in March 2026. Several services have moved to Legacy status.
The practical effect is structural, not cosmetic. A feature that triggers four or five SKUs no longer draws from one shared pool. Each SKU burns its own small allowance and then bills independently. Teams that built their forecast against the old credit model tend to find the gap in a Q2 or Q3 invoice rather than in a planning cycle.
HERE also raised list prices by 6% in April 2026. Both vendors moved.
What did not change is the difference between renting API calls and licensing a navigation runtime. That distinction survives every rate card revision, and it is the one worth getting right.
These are different products that get written into the same ticket.
An accurate ETA in the dispatcher’s console is a routing API call. It runs on your backend, it is cacheable, it is cheap, and it never touches the driver’s phone. Turn-by-turn guidance in the cab is a runtime executing on a device, holding map state, and reacting to GPS.
A surprising number of platforms buy the expensive one because the requirement was written as “add navigation” and nobody asked which half of the word was meant.
If your drivers operate anywhere with unreliable coverage, an online-only navigation stack is not a cost decision. It is a reliability decision that will surface as a support ticket, then as a churn conversation.
Embedded SDKs carry map data on the device and keep guiding when the connection drops. Request APIs cannot, by definition. If offline is a requirement, the architecture is already decided and the only remaining question is scope.
Height, weight, axle configuration, length, and hazmat class are where consumer-grade navigation stops being adequate.
A 13’6″ trailer routed under a 12’4″ overpass is not a routing inefficiency. It is a bridge strike, an insurance claim, and a DOT conversation. Consumer routing engines model a car because they were built for cars — the attributes simply are not in the request.
The example below is a real one. Same origin, same destination, one vehicle profile difference:
Standard routing sends the vehicle under the overpass: one violation, height exceeded by 14 inches. Truck-grade routing reroutes around it: zero violations, fully compliant, at a cost of one extra mile and 2.7 minutes.
That is the entire trade. Three minutes against a claim.
These restrictions are not exotic. Every fleet has its own version of that bridge somewhere on its lanes — the difference is whether the routing engine knows about it before the driver does.
If the map lives inside your product and your customers see your name on it, you are shipping a mapping feature, not consuming a service.
That changes the licensing conversation, the support model, and — usually — what you can charge for it. A white-labeled navigation experience is a line item in your own pricing page. A third-party map embed is a dependency.
| What you need | Request API | Navigation SDK |
| ETA in the dispatcher’s console | Yes | Not required |
| Route plan built before the driver leaves | Yes | Not required |
| Turn-by-turn guidance in the cab | No | Yes |
| Guidance that survives a dead zone | No | Yes |
| Truck attributes enforced during planning | Yes | Yes |
| Truck attributes enforced during guidance | No | Yes |
| Your brand on the map surface | Partial | Yes |
| Cost scales with | Requests | Devices and deployment scope |
Most fleet platforms need both. The mistake is buying them as one product, from one line item, on one pricing model.
Before comparing vendors, it is worth knowing what your own application actually triggers. Three common patterns, three different billing shapes:
| App pattern | Capabilities that fire | How it bills |
| Store locator (web) | Address autocomplete, geocoding, map load, place details, distance to nearest sites | Session, request, map load, request, request |
| Dispatch console (backend) | Batch geocoding, route calculation, matrix routing, service-area isolines, traffic-aware ETA | All per request — cacheable and cappable |
| Driver app (mobile) | Continuous map rendering, guidance session, reroute on deviation, offline map data, truck profile enforcement | Session and device — not per request |
Two things usually fall out of this exercise.
First, the store locator is almost always cheaper to fix than anyone expects. It is a stack of small request-based SKUs, several of which are cacheable, and at least one of which is usually firing more often than the product requires — autocomplete on every keystroke rather than on a debounce is a classic.
Second, the driver app is almost never the SKU problem people assume it is. It is a different purchase entirely, and treating it as a large version of the store locator is what makes the forecast wrong.
If you cannot produce this table for your own product in an afternoon, that is the finding. It means nobody currently owns the location cost line, which is the actual root cause in most of the invoices we look at.
Request-based location services have published, checkable rates. On the HERE Base Plan resold through Placematic, geocoding includes 30,000 free transactions per month and runs $0.88 per 1,000 above that. Routing includes 5,000 free requests per month, with truck routing counted as a standard routing request rather than a premium tier. Matrix routing includes 2,500. Map rendering starts at $0.088 per 1,000.
Against Google’s current per-SKU rates, high-volume geocoding and routing workloads typically land 40–70% lower. That range is not a promise — it depends entirely on which SKUs your application fires and at what volume, which is why the table above comes before the comparison.
Embedded navigation is not priced this way by anyone. It is scoped per deployment: device counts, offline map regions, vehicle profiles, platform coverage, update cadence. Any vendor quoting you a per-request figure for turn-by-turn guidance is quoting the wrong product, and the number will not survive contact with production.
Do not rip and replace. Split by SKU and sequence it.
Start with your highest-volume, lowest-risk workload. Usually batch geocoding or address validation. It is backend-only, it has no UI dependency, no design review, and no mobile release cycle. Move it, measure it over one full billing period, and use the recovered budget to fund the navigation decision — rather than fighting for new budget in a quarter where you have not yet proven anything.
Then separate your ETA layer from your guidance layer. Most fleet platforms discover they need a routing API for dispatch and an SDK for the cab, and that bundling both into one purchase is precisely what made the bill unpredictable. Once the two are separate line items, both become forecastable.
Validate truck attributes against your real lanes, not a demo route. Restriction data quality varies by corridor. The only test that means anything is your own historical routes replayed through a truck profile, with violations counted.
GreenLight ELD, an ELD provider in Joliet, Illinois, runs routing and geocoding this way — one contract, truck-grade routes, no in-house map team.
If you are looking at a location invoice that grew faster than your usage, the useful first step is not a vendor comparison. It is a breakdown of which SKUs drive the bill and which of those are load-bearing for your product.
We run that as a structured pilot on your real traffic — your routes, your volumes, your lanes. Not a slide deck.
CEO and Co-Founder of Placematic USA — a Location Intelligence company building spatial APIs and geomarketing software for fleet tech and logistics teams. HERE Technologies Gold Partner since 2016. Based in Rolling Meadows, IL.
Bart Taborowski