How to Choose a Geolocation API for Production

If you're selecting a geolocation API for a production use case - an address input form, courier routing, or GPS fleet tracking - and you want to understand what actually separates the options, this guide is for you. Most comparisons are just checkbox tables. Here we examine architecture, real pricing, technical constraints, and the scenarios in which each of six providers turns out to be the right or wrong choice.

---

1. What actually happens inside

Geocoding

Forward geocoding converts a text query (address or place name) into coordinates. Internally it's a search against an index built from map data. Result quality depends on how granularly the index covers addresses for a given region - down to country, city, street, building, or individual unit.

Reverse geocoding turns coordinates into an address. It's a spatial query against a polygon layer: the system finds which administrative unit and geometry the given coordinates fall within.

Place ID lookup fetches a full record by a stable ID returned in a previous response. Useful when you need a polygon boundary, object category, or a canonical address without issuing a new search query.

Routing

Routing algorithms work on a road graph: nodes are junctions, edges are road segments with attributes (speed limit, direction, vehicle restrictions). Shortest path is computed with a Dijkstra or A* variant weighted by a vehicle profile.

The profile determines which roads are accessible: a pedestrian can use footpaths, a truck skips bridges with weight limits, a bicycle prefers cycle lanes. "Shortest" doesn't necessarily mean by distance - you can optimize for time, fuel, or fewest turns.

Multi-stop order optimization is a variant of the Travelling Salesman Problem (NP-hard). In practice it's solved with heuristics: nearest neighbor, 2-opt, with support for time windows for deliveries with arrival constraints.

Address Search vs Geocoding

The key difference: Address Search is optimized for real-time UX - it returns candidates on partial input, ranked by proximity and likely intent, and doesn't require a complete address. Geocoding is deterministic: given a full query it returns the most probable match.

WebSocket Tracking

GPS tracking via API is fundamentally different from polling: the device establishes a persistent WebSocket connection and pushes fixes at a configured frequency. The server accepts the stream, stores history, and exposes REST access to current positions and historical tracks.

50 Hz means 50 fixes per second from a single device. That's appropriate for drones or precision positioning. For courier delivery, 1–5 Hz is sufficient.

---

2. What to measure when choosing

Rate limits and why they matter

A per-minute limit is a QPS ceiling. Daily and monthly limits are quotas.

The difference is critical for batch processing. If you need to geocode 200,000 addresses overnight, a 50 req/s limit lets you finish in ~67 minutes. With no per-minute cap, you're bounded only by your own infrastructure. During traffic spikes (feature launch, viral event), a per-minute ceiling returns HTTP 429 errors that end users see as failures.

Pricing model: per-request vs flat

Per-request: every call costs $X per 1,000. Predictable under steady load. Unexpectedly expensive during traffic spikes, bugs causing extra calls, or user growth.

Flat monthly: a fixed quota for a fixed fee. Costs don't change based on traffic within the quota. Overages are an opt-in, manageable decision.

Always calculate Total Cost of Ownership: add engineering time for integration, monitoring, error handling, and maintenance to the direct API cost. For self-hosted solutions, add server costs and operational burden.

Platform scope: one vendor or several

Most production applications need more than geocoding - they also need routing, address search, or tracking. When these live with different vendors, you accumulate:

• Multiple API keys and authentication schemes
• Multiple billing accounts and invoices
• Multiple documentation sets for the team
• Data consistency risk: geocoding via one provider, routing via another
• Different response formats to unify in your own code

Each additional vendor compounds maintenance complexity. A platform that covers multiple services under one key isn't just convenient - it's architectural simplicity.

Data sources and accuracy

OpenStreetMap is the largest open map dataset, community-maintained. Quality varies: excellent in well-mapped cities across Western Europe and North America, patchy in less-mapped regions.

Proprietary data (Google, HERE, TomTom) has been built over years through street-view surveys, government partnerships, and user contributions. The difference is especially visible for commercial POI (shops, restaurants, offices) and data freshness.

Licensing

OSM data is licensed under ODbL: attribution ("© OpenStreetMap contributors") is required in any public-facing product. For most API integrations this is a one-line UI element.

Google and Mapbox (Temporary) prohibit caching results. This constrains architectural decisions: you cannot save coordinates to a database and reuse them without re-querying.

---

3. Provider breakdown

Nominatim is the geocoder built as part of the OpenStreetMap project. Open source, built on PostgreSQL + PostGIS.

The public instance at nominatim.openstreetmap.org operates under a 1 request/second limit and explicitly prohibits commercial use. Suitable only for development, debugging, and non-commercial projects with minimal traffic.

Self-hosted deployment requires:

• Storage: planet import is 600–700 GB; country-level extracts are much smaller
• RAM: ≥64 GB for PostgreSQL index caching; less means significantly slower
• CPU: 8+ cores dramatically speed up initial import (which takes hours to days)
• Updates: minutely diffs from OSM, but reindexing changes is not instantaneous

What it does: forward geocoding, reverse geocoding, OSM tag search, administrative boundary polygons.
What it doesn't do: routing, address autocomplete, device tracking. Each requires a separate stack (OSRM/Valhalla, Pelias, custom system).

Google Maps Platform is a suite of APIs, not a single product. Geocoding, Directions, and Places are three separate services with separate pricing, separate documentation, and separate rate limits.

Real cost of a full stack (2026):

• Geocoding API: $5.00 per 1,000 requests
• Directions API (basic): $10.00 per 1,000; with live traffic: $20.00
• Places API (details): $17–32 per 1,000 depending on fields requested

In a "show address + route + place details" scenario, three API calls compound. At one million such user sessions per month, that's $30,000–50,000+ in API costs alone.

Rate limits: 50 requests/second by default. Exceeding this returns HTTP 429. The limit can be raised through Google Cloud Console, but requires a request and in some cases additional agreements.

Data quality: Google's commercial POI data - businesses, brands, obscure venues - is genuinely unmatched. Fresh, granular, globally consistent. If your product's core promise is "find any business by name anywhere in the world," Google is the right choice regardless of cost.

Vendor lock-in:place_id is a Google-ecosystem identifier not compatible with any other provider. If you store place_ids in your database, migrating to a different provider requires re-geocoding all records.

Attribution: "Powered by Google" is required in any UI displaying the data.

Mapbox is positioned differently from Google: its core value is developer tooling and map rendering. Their GL JS and mobile SDKs are the industry standard for polished interactive maps.

A critical split in geocoding tiers:

• Temporary Geocoding API - standard search. Results may not be cached or stored (Terms of Service). First 100,000 requests/month free, then $0.75/1k → $0.60/1k → $0.45/1k.
• Permanent Geocoding API - batch geocoding with the right to store results. No free tier: $5.00/1k (up to 500k), $4.00/1k (500k+). Comparable to Google's pricing.

If you need to geocode and persist results, Temporary doesn't cover you by license. Moving to Permanent multiplies costs significantly.

Directions API: free up to 100k, then $2.00/1k → $1.60/1k → $1.20/1k.
Optimization API (multi-stop): exists, $2.00/1k after 100k free. Often overlooked in comparisons.
Rate limits: 600 requests/minute across most services.

Tracking: no WebSocket position streaming, no device management API. Fleet tracking requires a separate stack.

HERE is a mature platform with a history in automotive navigation - HERE Map data is used in in-vehicle systems for BMW, Mercedes, Audi, and others. Decades of data investment are visible, especially in Europe and Japan.

Geocoding pricing (from their pricing page):

At 1 million requests: (1,000,000 − 30,000) × €0.70 / 1,000 ≈ €679/month.

Fleet Tracking: HERE Tracking is a separate IoT platform with its own onboarding and enterprise pricing. Not bundled with the geocoding API.

TomTom transformed from a navigation device manufacturer into a geolocation API platform. Their core competitive advantage is live traffic data sourced from a probe vehicle network: real-time speed data from hundreds of millions of connected devices.

Free tier: 2,500 requests/day for geocoding. That's ~75,000/month - enough for development, insufficient for production.
Paid tier: per-request; check current pricing at TomTom's site.
Traffic-aware routing: live ETA is the standard mode - no separate traffic layer to enable.
Tracking: no WebSocket streaming or device management.

PickPoint brings four geolocation APIs under one key and one quota.

One key, four APIs:

• Geocoding API - forward (GET /v2/geocode/forward), reverse (/v2/geocode/reverse), lookup (/v2/geocode/lookup)
• Routing API - 10+ vehicle profiles, POST /v2/route/optimized for multi-stop orders
• Address Search API - autocomplete + place ID lookup
• Device Tracking API - WebSocket up to 50 Hz, REST for device management and track history

Pricing: flat monthly plans. No per-request billing - costs don't change based on call volume within the quota.

Rate model: no per-minute caps. For batch geocoding this means sending 50,000 requests in an hour without 429 errors - if the daily quota allows. No throttler needed between your code and the API.

Multi-stop optimization supports time windows: each waypoint can have a defined arrival window, needed for delivery with assigned slots.

Data: OSM + commercial feeds, continuously updated from live changesets.

---

4. Pricing calculations

Geocoding only (forward geocoding, no routing) at three scales:

Notes: Google includes a $200 monthly credit (~40k free requests). Nominatim self-hosted has no per-request cost but server and ops costs apply. PickPoint range reflects different plan tiers.

Add routing

Real scenario: geocoding an address then building a route. At 1 million requests each per month:

Nominatim self-hosted: the real TCO

Nominatim is often described as "free." The full picture:

• Cloud server (8 cores, 64 GB RAM, 800 GB SSD): $200–400/month
• Initial import and setup: 8–16 engineering hours (one-time)
• Maintenance: update pipeline, monitoring, fallback on failures - minimum 2–4 hours/month
• At $80/hour: $160–320/month in ops

---

5. One query, four implementations

Geocoding "Battery Place, 17, New York" - the same request across each API:

# Nominatim (development / non-commercial only)
GET nominatim.openstreetmap.org/search
  ?q=Battery+Place+17&format=json
  User-Agent: myapp/1.0

# Google Geocoding API
GET maps.googleapis.com/maps/api/geocode/json
  ?address=Battery+Place+17&key=YOUR_KEY

# Mapbox (Temporary - caching prohibited)
GET api.mapbox.com/geocoding/v5/mapbox.places
  /Battery+Place+17.json?access_token=TOKEN

# PickPoint
GET api.pickpoint.io/v2/geocode/forward
  ?q=Battery+Place+17
  X-API-KEY: YOUR_KEY

Response structure comparison

Nominatim - array with lat/lon as strings:

[{
  "lat": "40.7051606",
  "lon": "-74.0159868",
  "display_name": "17, Battery Place, Manhattan...",
  "class": "building",
  "type": "apartments"
}]

Google - results[] object, lat/lon as numbers inside geometry.location:

{
  "results": [{
    "geometry": {
      "location": {
        "lat": 40.7051606,
        "lng": -74.0159868
      }
    },
    "formatted_address": "17 Battery Pl, New York, NY 10004",
    "place_id": "ChIJmQJIxlVYwokRLgeuocVOGVU"
  }]
}

Mapbox - GeoJSON FeatureCollection, coordinates [lon, lat]:

{
  "features": [{
    "geometry": {
      "type": "Point",
      "coordinates": [-74.0159868, 40.7051606]
    },
    "place_name": "17 Battery Place, New York, NY 10004",
    "id": "address.8524..."
  }]
}

PickPoint - array similar to Nominatim, with a structured address block:

[{
  "lat": "40.7051606",
  "lon": "-74.0159868",
  "display_name": "17, Battery Place, Manhattan...",
  "class": "building",
  "type": "apartments",
  "address": {
    "house_number": "17",
    "road": "Battery Place",
    "city": "New York",
    "postcode": "10004",
    "country_code": "us"
  }
}]

---

6. Migrating to PickPoint

For most geocoding tasks, the switch is a URL change and a header:

From Nominatim

- nominatim.openstreetmap.org/search?q=...&format=json
+ api.pickpoint.io/v2/geocode/forward?q=...
  X-API-KEY: YOUR_KEY

# Response format is largely compatible:
# result[0].lat  - identical
# result[0].lon  - identical
# PickPoint also returns result[0].address
# with: house_number, road, city, postcode

From Google Geocoding

- maps.googleapis.com/maps/api/geocode/json
  ?address=...&key=YOUR_KEY
+ api.pickpoint.io/v2/geocode/forward?q=...
  X-API-KEY: YOUR_KEY

# Adapt:
# results[0].geometry.location.lat  →  result[0].lat
# results[0].geometry.location.lng  →  result[0].lon
# formatted_address                 →  result[0].display_name
# place_id - Google ecosystem ID, not portable

From Mapbox Geocoding

- api.mapbox.com/geocoding/v5/mapbox.places/
  QUERY.json?access_token=YOUR_TOKEN
+ api.pickpoint.io/v2/geocode/forward?q=...
  X-API-KEY: YOUR_KEY

# Mapbox → GeoJSON, PickPoint → lat/lon array
# features[0].geometry.coordinates[1]  →  result[0].lat
# features[0].geometry.coordinates[0]  →  result[0].lon
# Note: Mapbox coordinates are [lon, lat]

---

7. Questions that determine your choice

1. Do you need routing and/or GPS tracking alongside geocoding?
   If yes - this is the most important question. Nominatim has no routing API. TomTom has no tracking. Google requires Fleet Engine (Enterprise) and Directions as separate products. PickPoint covers all three under one key.
2. Do you plan to expand your geolocation stack over time?
   If you're starting with geocoding but routing or tracking is on your roadmap, it makes sense to choose a platform that scales with your product now - rather than re-evaluating vendors a year from now.
3. Do you have batch processing or burst traffic?
   Google's 50 QPS and Mapbox's 600 req/min limits require throttle-and-retry logic in your code. That's not just extra lines - it means added latency. No per-minute cap means batch jobs work simply.
4. Is predictable cost important for financial planning?
   With per-request billing (Google, Mapbox), invoices depend on traffic. With flat billing (PickPoint), they don't. For SaaS companies with variable load, this matters for unit economics.
5. Is commercial POI accuracy the primary requirement?
   If "find any business by name" is the key feature - Google. Their proprietary data quality for business lookup is unmatched, and worth the cost as an honest recommendation.
6. Is live traffic data core to the experience?
   TomTom. Their probe vehicle network is a genuine competitive advantage for real-time ETA and congestion-aware routing.
7. Do you have an automotive or government contract with data quality requirements?
   HERE. Decades of investment in proprietary map data are difficult to replicate.
8. Is this a prototype or non-commercial project with zero budget?
   Nominatim self-hosted. Deploys for free; switching to a managed provider is a URL change.

Data accurate as of July 2026. Pricing and features change - verify with each provider's official documentation before making a decision: Nominatim, Google, Mapbox, HERE, TomTom, PickPoint.