​

HERE Geocoding and Search

Half of what teams call a geocoding cost problem is a geocoding caching problem. Addresses do not move. Re-geocoding the same customer address on every order is the most common avoidable spend on this entire platform, and it is fixed with a database column.

​

What problem this guide solves

You have address text. You need coordinates, a normalized address, and a confidence signal. You may also need type-ahead in a UI, or a free-text place search, or to process a million rows overnight. These are four different endpoints with four different cost profiles, and teams routinely use the most expensive one for all four jobs.

​

The endpoint family

HERE Geocoding & Search v7 exposes distinct endpoints for distinct jobs: Full endpoint list and base URL: HERE Geocoding and Search API v7 endpoints.

​

When to use each

/geocode — Server-side address resolution. Batch imports where each record is a full address. Anywhere you have a complete address and need a point. /autocomplete — Address entry fields. Checkout. Dispatcher address input. Cheap, fast, address-scoped. /autosuggest — Search boxes where users type place names, misspell things, or type partial categories. Handles spelling correction and term completion. /discover — Free-text search where the user’s intent is unstructured. “Coffee near Wrigley Field.” /browse — Category-filtered place lists ranked by distance. Store finders. “Show me pharmacies within 2 km.” Batch API v7 — Any workload where nothing is waiting. See below.

​

When NOT to use HERE geocoding

Be honest about this before you migrate. HERE is strong on street addresses. It is adequate on POIs. Choose per use case, not per vendor. A hybrid architecture — HERE for address resolution and routing, Google for place discovery — is a defensible and common outcome. See HERE vs Google Maps. Also skip HERE geocoding when:

• You are geocoding fewer than ~10k addresses a month. The savings are a rounding error against migration cost.
• The address is already geocoded and cached. Which brings us to the main point.

​

Real-time versus batch

Same data. Different product. Materially different price. Batch API v7 is a job API, not a bulk endpoint. The lifecycle is explicit:

1. POST to create a job → returns 201 with a job ID
2. Start the job
3. Poll job status
4. Retrieve results as a downloadable stream
5. Retrieve errors separately, if any
6. Delete the job

HERE documents job status, job lifecycle, and limits and performance as separate concerns. Read all three before building. Notable behaviours worth knowing before you architect:

• Exceeding the concurrent job limit returns 429 on job start
• A completed job with no errors returns 204 on the errors endpoint, not an empty 200
• Results are not available until the job succeeds; querying early returns 404
• Gzip compression is supported and worth using on large inputs
• Webhook notifications on completion exist in beta, with substitutable placeholders like ${JOB_ID} and ${JOB_STATUS}

The tell: if the geocoding result is written to a database rather than rendered to a screen, it should have been batched.

​

Caching: the section that saves you money

Do this before you evaluate any vendor. Cache in your own datastore, not in a request-scoped memo. Store the normalized address, coordinates, HERE ID, and a result-quality signal alongside the customer or location record. Key on the normalized address, not the raw input. 123 Main St and 123 Main Street should hit the same cache entry. Set a long TTL. Buildings persist. Rebuild the cache when HERE ships significant map updates, not on a two-week schedule because it felt prudent. Store the confidence signal. HERE returns result scoring and result types. A low-confidence match is a data quality problem you want surfaced, not silently persisted as truth.

​

Production architecture

Normalize before you geocode. Trimming, case-folding, and expanding abbreviations at write time increases cache hit rate for free. Use result types to filter. HERE distinguishes address results from place results and supports filtering by type. An address field that accepts a place result will store a shopping centre where a street address belonged. Handle house-number fallback deliberately. HERE supports falling back when an exact house number is unavailable. Whether that fallback is acceptable depends on whether you are shipping a parcel or scoring a site. Decide explicitly. Country filtering narrows results and reduces ambiguity. If your product operates in one market, say so in the request. Political views matter for disputed territories. HERE exposes political view handling. If you serve multiple markets, this is a legal and product decision, not a technical default. Rate limits are commercial. A persistent 429 means your quota does not match your workload. See Authentication.

​

Cost and usage considerations

Each request is one billable transaction. Autocomplete fires on keystrokes — a naive implementation bills once per character typed. Where teams overspend:

• No cache. The largest single item, every time.
• Autocomplete without debouncing. Debounce at 200–300ms. Do not fire on every keypress.
• Real-time geocoding for overnight work. Batch is cheaper per record.
• Autosuggest where autocomplete would do. Different endpoints, different costs.
• Geocoding on every order for a stable customer address.

Geocoding-heavy workloads see the largest savings when moving from Google — typically 80%+ at production volume — but only after you have fixed the call pattern. Migrating an uncached, undebounced implementation just moves the waste to a cheaper meter. See HERE Pricing Explained.

​

Common mistakes

No persistent cache. Fix this first, on whatever platform you are on. Autocomplete on every keystroke. Debounce. Confusing /autocomplete with /autosuggest. Addresses versus places. Using real-time endpoints for batch workloads. Use the Batch API. Treating Batch API as a synchronous bulk endpoint. It is a job lifecycle. Poll it. Polling batch results before job completion. 404 is expected, not an error to retry aggressively. Storing a low-confidence match as truth. Persist the score. Accepting a place result in an address field. Filter by result type. Expecting Google-quality POI data. You will not get it. Plan the hybrid.

​

Best practices

• Cache normalized address → coordinates in your own database, with a long TTL
• Debounce autocomplete input
• Batch anything that tolerates latency
• Filter by result type and by country
• Persist and act on the confidence score
• Decide house-number fallback policy explicitly
• Read the Batch API limits page before designing the job pipeline
• Keep Google for consumer place discovery if that is your product

​

API reference

• Introduction to HERE Geocoding & Search API v7
• Endpoint list
• Batch API v7 quick start
• Batch API limits and performance
• Result types

​

Related guides

Also: Authentication · HERE vs Google Maps

---

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.