Google Maps Platform: Places vs Routes vs JS API — Which SKUs Fire and How Bills Stack

Google Maps Platform pricing is not based on “using Google Maps” in a generic way. It is based on which SKU fires.

That distinction matters.

A simple-looking location flow can trigger one SKU. A richer journey with a map, autocomplete, place details, route calculation and street view can trigger several different SKUs in the same user session.

This is the pattern behind many surprise bills.

Google defines a SKU as a distinct billable item associated with a Google Maps Platform product, and requests to some services can trigger one or more SKUs, each appearing as a separate line item on the bill.

Source: Google Maps Platform SKU details

If you run a B2B SaaS product or marketplace, your “find a provider near me” or “search by location” flows can quietly trigger several SKUs per session. This guide shows how those SKUs stack in real SaaS journeys, and how to redesign them so you keep the UX but avoid margin-killing surprises.

This article explains the practical difference between Places, Routes and the Maps JavaScript API, which SKUs typically fire, and how those SKUs stack when you combine them in a real product flow.

---

The short version

If you only remember one thing, remember this:

The Maps JavaScript API usually bills for displaying the map. Places bills for finding or enriching locations. Routes bills for calculating journeys.

They are related, but they are not the same billing unit.

The mistake is assuming that because everything appears inside one map interface, it is all one “Maps API” cost. It is not.

---

How Google Maps Platform billing works

Google Maps Platform uses a pay-as-you-go model. Pricing is calculated per billable event, grouped by SKU, with monthly usage tiers and volume discounts. Google aggregates usage across projects linked to the same billing account to determine the applicable tier.

Source: Google Maps Platform pricing

In practice, your monthly bill is built like this:

Monthly bill =
  Dynamic Maps events
+ Autocomplete events
+ Place Details events
+ Routes events
+ Route Matrix events
+ any other SKUs triggered
- free monthly usage caps
+ any overage from subscriptions or excluded SKUs

The important part is that each SKU has its own rules, free usage cap, and price per 1,000 events.

For example, in the current global pricing list, Dynamic Maps has a free usage cap of 10,000 monthly events, then $7.00 per 1,000 events for the 10,001–100,000 range. Static Maps has the same 10,000 monthly event cap and starts at $2.00 per 1,000 events in its first paid tier.

Source: Google Maps Platform pricing

Two map implementations that look almost identical to users can therefore land in very different pricing buckets.

Note: all prices here use Google’s global USD list as of May 2026 and ignore currency, region and subscriptions. Always confirm the latest values in the Google Maps Platform pricing table before making budget decisions.

---

Product 1: Maps JavaScript API

The Maps JavaScript API is what most teams think of when they say “we embedded Google Maps”.

It lets you render an interactive map in the browser. But it can also be used together with libraries and services that trigger additional SKUs. Google’s own documentation says Maps JavaScript API requests generate calls to different SKUs depending on the type of request: map loads trigger Dynamic Maps, panoramas trigger Dynamic Street View, and calls to the Places Library and other JavaScript services are priced separately.

Source: Maps JavaScript API usage and billing

Common Maps JavaScript API SKUs

Prices above are from the Google Maps Platform global pricing list for the first paid usage tier.

Source: Google Maps Platform pricing

When does Dynamic Maps fire?

Dynamic Maps usually fires when an interactive map loads in the browser.

A common implementation:

<div id="map"></div>

<script>
  function initMap() {
    var map = new google.maps.Map(document.getElementById("map"), {
      center: { lat: 51.5072, lng: -0.1276 },
      zoom: 12
    });
  }
</script>

From a billing perspective, the key event is not whether the user clicks the map. It is that the interactive map loads.

Cost implication

If your page gets 80,000 map loads in a month:

10,000 free Dynamic Maps events
70,000 paid Dynamic Maps events
70,000 / 1,000 × $7.00 = $490

That is before any Places, Routes, Street View or other API usage.

In a SaaS product with thousands of daily workspaces or tenants, auto-loading a map on every dashboard visit can quietly erode gross margin without adding real value. Treat map loads like any other paid infrastructure resource.

---

Product 2: Places API

Places is about finding, identifying and enriching locations.

It powers things like autocomplete search boxes, place IDs, business names, addresses, ratings, opening hours, phone numbers, photos and nearby search.

Places is powerful, but it is also where SKU selection becomes more sensitive.

Google’s Places API documentation says billing is based on the features used in the request, and that for Place Details, Nearby Search and Text Search you should use field masks to specify only the fields you need. If you request fields from multiple SKU categories, you are billed at the highest applicable SKU.

Source: Places API usage and billing

That one sentence is very important.

It means that “Place Details” is not always one price. The fields you request can move the request into a higher SKU.

Common Places API SKUs

Prices and free caps above are from Google’s global pricing list for Places API New.

Source: Google Maps Platform pricing

The Places decision tree

Use this mental model:

Do you only need a place ID?
→ Use ID-only fields where possible.

Do you need the formatted address, location or display name?
→ Likely Place Details Essentials.

Do you need richer business or commercial information?
→ Could move into Place Details Pro or Enterprise.

Do you need ratings, atmosphere, reviews, opening hours or photos?
→ Check field masks carefully. You may trigger higher SKUs.

Do you need a list of nearby businesses?
→ Nearby Search Pro or Enterprise is likely.

Do you need search results from text like “plumbers near Manchester”?
→ Text Search Pro or Enterprise is likely.

Why field masks matter

A Place Details request that asks only for essential fields can be much cheaper than a request that asks for everything.

Bad pattern:

// Avoid requesting broad data unless you really need it.
fields: ["*"]

Better pattern:

fields: ["id", "displayName", "formattedAddress", "location"]

The principle is simple: do not request fields just because they are available.

In Google’s current model, the data you ask for can change the SKU.

---

Product 3: Routes API

Routes is about journeys.

Use it when you need to calculate how to get from one place to another, estimate travel time, compare route options, calculate distances, or create origin/destination matrices.

Common Routes API SKUs

Prices above are from Google’s global Routes API pricing list.

Source: Google Maps Platform pricing

Routes decision tree

Do you need one route from A to B?
→ Compute Routes Essentials may be enough.

Do you need many origins and destinations?
→ Compute Route Matrix is more likely.

Do you need traffic-aware routing, route modifiers or more advanced route features?
→ You may move into Pro.

Do you need fleet-level optimization?
→ Route Optimization / Enterprise SKUs may apply.

Cost implication

If you calculate 60,000 standard routes in a month:

10,000 free Compute Routes Essentials events
50,000 paid events
50,000 / 1,000 × $5.00 = $250

But if the same flow uses advanced route features and triggers Compute Routes Pro:

5,000 free Compute Routes Pro events
55,000 paid events
55,000 / 1,000 × $10.00 = $550

Same number of route calculations. Different SKU. Different bill.

For marketplaces, it is often enough to rank providers by approximate distance and only call the Routes API when the buyer actually clicks a specific provider or starts a checkout flow. That keeps routing costs proportional to serious intent, not casual browsing.

---

How bills stack in real product flows

The easiest way to understand Google Maps Platform pricing is to stop thinking API-by-API and start thinking user journey-by-user journey.

A user does not “use the Places API”. A user opens a page, searches for a location, selects a result, views a map, calculates a route and maybe opens Street View.

Each of those steps can fire a different SKU.

For SaaS and marketplaces, the key question is not just “What is my total Maps bill?” but “How many cents per active user, per search, or per transaction?” Once you know the SKU cost per core action (for example, “search for providers” or “request directions”), you can decide whether to lazy-load, cache, or change UX to protect your margins.

A simple way:

1. Measure Dynamic Maps / Autocomplete / Place Details / Routes events for a month
2. Divide each by active workspaces, active users or completed transactions
3. Use those as rough COGS-per-unit for location features

---

Example 1: Simple store locator

Flow:

1. User opens a store locator page.
2. Page loads an interactive map.
3. User types a postcode.
4. App geocodes the postcode.
5. App shows nearby stores from your own database.

Possible SKUs:

This is relatively cost-efficient because Google is only used for map display and geocoding. The store search happens in your own database.

---

Example 2: Autocomplete address lookup with map

Flow:

1. User opens a page with an address field.
2. User types into an autocomplete input.
3. User selects an address.
4. App fetches place details.
5. App loads an interactive map centred on that place.

Possible SKUs:

This is where a lot of teams underestimate cost. They count the map load but forget autocomplete and place details.

For example, 50,000 users might not mean 50,000 billable events. If each user types several autocomplete requests, selects a result, and loads a map, the SKU count can be much higher than the session count.

---

Example 3: Lead generation location journey

Flow:

1. User lands on a campaign page.
2. Map loads.
3. User enters postcode.
4. App finds nearest providers.
5. User clicks “get directions”.
6. App calculates the route.

Possible SKUs:

This type of journey can become expensive if every page view triggers a map and every provider card triggers route or matrix calculations.

A better pattern is often:

Load page
→ Do not load map immediately
→ Ask for postcode
→ Query internal database first
→ Load Google map only when location results are needed
→ Calculate route only after explicit user interaction

That avoids firing expensive SKUs for users who never engage.

---

Example 4: “Find nearby businesses” search

Flow:

1. User enters “dentist near me”.
2. App uses Google Places Text Search or Nearby Search.
3. App shows results.
4. User clicks a result.
5. App fetches details and photos.

Possible SKUs:

This is a much more Google-dependent flow. You are not just using Google to display a map. You are using Google as the search and business data layer.

That can be valid, but it needs deliberate cost modelling.

---

Example 5: B2B marketplace matching buyers and providers

Flow:

1. Buyer lands on “Find a consultant/installer near you”.
2. Buyer enters postcode or business address.
3. Marketplace lists matching providers sorted by distance or priority.
4. Buyer opens a provider profile with a map and “Get directions”.
5. Buyer optionally compares travel times to multiple providers.

Possible SKUs:

In marketplace settings, this pattern often runs at high volume with thin per-transaction margins. If you calculate routes or ETAs for every search result instead of on click, your routing SKUs can quietly become one of your biggest COGS line items.

---

Places vs Routes vs Maps JavaScript API: practical comparison

---

The hidden cost pattern: one UI, many SKUs

A common frontend build looks like this:

Interactive map
+ autocomplete input
+ selected place details
+ nearby search
+ route calculation

From a user’s perspective, this is one component.

From a billing perspective, it may be:

Dynamic Maps
+ Autocomplete Requests
+ Place Details
+ Nearby Search
+ Compute Routes

That is why Google Maps Platform cost reviews should happen at the journey level, not just the API-key level.

Ask:

1. What loads on page view?
2. What loads only after user interaction?
3. What fires on every keystroke?
4. What fires once per selected result?
5. What fires once per provider/location card?
6. What fires in the background without the user seeing it?
7. Which fields are requested from Places?
8. Which route features are enabled?
9. Which SKUs appear in Cloud Billing after QA traffic?

---

Cost stacking example

Imagine this monthly usage:

Approximate total:

$490 + $459.70 + $200 + $100 = $1,249.70

This is only an illustrative model, but it shows the important point: the map itself may not be the full cost driver.

Autocomplete, details, search and routing can stack on top.

Google’s pricing page shows tiered billing in action. For example, 200,000 Autocomplete Request events are calculated across the free tier, the 10,001–100,000 tier, and the 100,001–500,000 tier, producing a total monthly cost of $481.70 in Google’s example.

Source: Google Maps Platform pricing

---

How to reduce Google Maps Platform costs

1. Do not load maps before the user needs them

If a page has high traffic but low map engagement, lazy-load the map.

Bad pattern:

Page load → immediately load Google Map

Better pattern:

Page load → show lightweight placeholder
User enters location or clicks “View map”
→ load Google Map

This can reduce Dynamic Maps events dramatically, especially in SaaS dashboards and marketplace search pages where most users never open the map.

---

2. Use your own database for known locations

If you already have a list of clinics, installers, stores or branches, do not use Places Nearby Search to rediscover them on every visit.

Better pattern:

User postcode
→ geocode once
→ search your own location database
→ show nearest locations

Use Google only where it adds value: geocoding, map display, routing or address selection.

---

3. Be strict with Places field masks

Field masks are one of the most important cost controls in Places API.

Google states that for Place Details, Nearby Search and Text Search, you are billed at the highest SKU applicable to your requested fields.

Source: Places API usage and billing

That means you should define field groups intentionally.

Example:

const fields = [
  "id",
  "displayName",
  "formattedAddress",
  "location"
];

Avoid broad “give me everything” requests unless the business case justifies the extra cost.

---

4. Debounce autocomplete

Autocomplete can fire repeatedly as a user types.

Use sensible debounce logic so you are not sending unnecessary requests.

Example:

var autocompleteTimer;

function handleInput(value) {
  clearTimeout(autocompleteTimer);

  autocompleteTimer = setTimeout(function () {
    if (value.length < 3) {
      return;
    }

    fetchAutocompleteSuggestions(value);
  }, 300);
}

Also avoid firing autocomplete on empty or very short strings.

---

5. Calculate routes only after intent

Do not calculate routes for every result card by default.

Bad pattern:

User enters postcode
→ show 20 providers
→ calculate route for all 20 providers immediately

Better pattern:

User enters postcode
→ show 20 providers ranked by approximate distance
→ calculate route only when user clicks “View travel time”

If travel time is central to the ranking, use a route matrix carefully and cache where appropriate.

---

6. Cache stable results where allowed

Some location data changes slowly. Some user journeys repeat similar lookups.

Review Google’s terms and caching rules for the specific API you use, but from an architecture perspective, avoid repeated paid calls for the same internal workflow where caching is permitted.

---

7. Set quotas and budget alerts

Google recommends using quota limits, quota alerts, and Cloud Billing budgets to manage costs. It also warns that quotas are not the billing source of truth and billing data can have latency, so quota limits should be set with a margin if used for budget protection.

Source: Manage Google Maps Platform costs

Practical setup:

1. Restrict API keys
2. Set per-API quotas
3. Create budget alerts
4. Monitor SKU-level billing
5. Review usage after QA and after launch

---

SKU audit checklist

Use this before launching any Google Maps Platform feature.

Page load

• Does the map load immediately?
• Can it be lazy-loaded?
• Is a static map enough?
• Is the map below the fold?

Places

• Are you using Autocomplete?
• How many requests fire per user?
• Are you using session tokens correctly?
• Do you fetch Place Details after selection?
• Which fields are requested?
• Are any Pro or Enterprise fields included?
• Are you using Nearby Search or Text Search when your own database would work?

Routes

• Are you calculating one route or many?
• Are routes calculated automatically or after a click?
• Are you using traffic-aware routing?
• Are you using route matrices?
• Are you calculating routes for locations the user may never view?

Billing

• Which SKUs appear in Cloud Billing?
• Are free usage caps being exceeded?
• Are SKUs split across multiple projects under the same billing account?
• Are API keys restricted?
• Are quotas and budget alerts configured?
• Has QA traffic been separated from production where possible?

---

Implementation pattern: cost-efficient location finder

A cost-efficient finder usually looks like this:

1. User enters postcode or address
2. Use address autocomplete or geocoding only when needed
3. Convert input to coordinates
4. Search internal database for nearest locations
5. Render lightweight results first
6. Load interactive map only if the user engages
7. Calculate routes only for selected locations

This avoids the most expensive pattern:

Page load
→ load map
→ fire autocomplete repeatedly
→ fetch full place details
→ run nearby search
→ calculate many routes
→ show everything whether the user needs it or not

---

Technical example: lazy-load Google Maps after user interaction

<button id="load-map-button">View map</button>
<div id="map" style="height: 400px;"></div>

<script>
  var mapLoaded = false;

  function loadGoogleMapsScript(callback) {
    if (mapLoaded) {
      callback();
      return;
    }

    var script = document.createElement("script");
    script.src = "https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap";
    script.async = true;
    script.defer = true;

    window.initMap = function () {
      mapLoaded = true;
      callback();
    };

    document.head.appendChild(script);
  }

  function createMap() {
    new google.maps.Map(document.getElementById("map"), {
      center: { lat: 51.5072, lng: -0.1276 },
      zoom: 12
    });
  }

  document.getElementById("load-map-button").addEventListener("click", function () {
    loadGoogleMapsScript(createMap);
  });
</script>

This pattern prevents a Dynamic Maps event from firing for users who never open the map.

---

Technical example: safer Places field selection

async function getPlaceDetails(placeId) {
  var response = await fetch("https://places.googleapis.com/v1/places/" + placeId, {
    method: "GET",
    headers: {
      "Content-Type": "application/json",
      "X-Goog-Api-Key": "YOUR_API_KEY",
      "X-Goog-FieldMask": "id,displayName,formattedAddress,location"
    }
  });

  if (!response.ok) {
    throw new Error("Place Details request failed");
  }

  return response.json();
}

The key part is the field mask:

id,displayName,formattedAddress,location

Do not request richer fields unless the interface actually uses them.

---

Technical example: route calculation only after click

function attachRouteButtons() {
  var buttons = document.querySelectorAll("[data-route-destination]");

  buttons.forEach(function (button) {
    button.addEventListener("click", function () {
      var destination = button.getAttribute("data-route-destination");
      calculateRoute(destination);
    });
  });
}

async function calculateRoute(destination) {
  var response = await fetch("/api/calculate-route", {
    method: "POST",
    headers: {
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      origin: "USER_SELECTED_LOCATION",
      destination: destination
    })
  });

  if (!response.ok) {
    throw new Error("Route calculation failed");
  }

  return response.json();
}

This avoids calculating routes for every location card by default.

---

Common mistakes

Mistake 1: Treating the API key as the cost unit

The API key is not the cost unit. The SKU is.

One API key can trigger many SKUs.

Mistake 2: Loading the map on every landing page visit

If only a small percentage of users interact with the map, loading it for everyone can waste budget.

Mistake 3: Using Places search instead of your own database

If you already know your locations, use your own data. Google does not need to search the public Places database every time.

Mistake 4: Requesting too many Place Details fields

The more fields you request, the more likely you are to trigger higher Places SKUs.

Mistake 5: Calculating routes too early

Routes should usually be calculated after intent, not automatically for every possible destination.

Mistake 6: Ignoring SKU-level billing reports

You cannot optimise what you only view as a total Maps Platform bill. Review SKU-level usage.

---

Final recommendation

Use this rule of thumb:

Maps JavaScript API = visual display
Places API = location discovery and enrichment
Routes API = travel calculation

Then model the user journey step by step.

For each step, ask:

Does this step display a map?
Does this step search or enrich a place?
Does this step calculate a journey?
Does it happen on page load, on typing, on selection, or after a click?
Which SKU appears in billing?
Can this be delayed, reduced, cached or moved to internal data?

That is the difference between a predictable Google Maps Platform implementation and a surprise bill.

---

Work with me on your SaaS or marketplace

If you want a broader overview of Maps vs Routes vs Places and the $200 monthly credit, you can read my guide on Google Maps APIs uses and costs.

If you run a B2B SaaS or marketplace and your Google Maps bill is starting to hurt your margins, I help teams:

• Model Google Maps SKUs against unit economics.
• Redesign flows so you keep conversion but reduce COGS.
• Set up monitoring and guardrails before costs get out of control.

You can book a short SKU-level audit and architecture review on nicolalazzari.ai.

---