Google Maps integration for web and mobile apps

Google Maps Platform provides map, geocoding, places and routing APIs for websites, Android apps and iOS apps. We build the features around them: maps that show your own data, address search and autocomplete, route and distance calculations, and the key and cost controls that keep usage predictable.

Talk through your maps project Request an estimate

Maps, address search and routes in web, Android and iOS apps
Places API (New) and Routes API for new builds
API keys restricted and costs watched from the start
Designs that respect Google's rules on storing results

When Google Maps is the right choice

Google Maps Platform suits products that need location features from one provider:

You need several services together: maps, geocoding, place search and autocomplete, and routing with real-time traffic.
You need native SDKs for Android and iOS as well as a web API.
You need server-side conversion between addresses, coordinates and Place IDs.
You want billing and quota control through Google Cloud budgets and quotas.

When Google Maps is not the right choice

Google Maps Platform has limits worth knowing before you design around it:

It is pay-as-you-go and needs a billing account, so it is a poor fit where cost must be zero or fixed.
Places content must be shown on a Google map with attribution, or with the Google logo when there is no map. That limits mixing it into another map provider.
Places content may not be pre-fetched, cached or stored beyond the stated exceptions. That constrains offline apps and designs that build their own database of places.
Where those limits matter, we compare other map providers with you before committing.

What we build with Google Maps

Typical projects, described in general terms.

Maps with your data

Interactive maps with markers, shapes and styling that show your own locations, territories or vehicles.

Address search

Autocomplete and place details, so people pick a real address instead of typing it in full.

Routes and distances

Driving, walking, transit and multi-stop routes, with real-time traffic where the service supports it.

Geocoding

Turning addresses into coordinates and back, for dispatch, delivery, reporting and location-based search.

Key security and cost control

Restricted keys, separate keys per app, budgets and quotas, so a leaked key or a loop does not become a surprise bill.

Moving off legacy APIs

Upgrading from the Directions, Distance Matrix and original Places APIs to the Routes API and Places API (New).

Which Google Maps APIs we use

Google groups its services under Maps, Routes, Places and Environment. The ones most projects use are the Maps JavaScript API for websites, the Maps SDKs for Android and iOS, the Places API (New) for search, autocomplete and place details, the Geocoding API, the Routes API for directions, and the Maps Static API for images. For device location, Google's own guidance is to prefer the browser, Android or iOS location features where they exist, and use the Geolocation API when they do not.

Google lists the Directions API, the Distance Matrix API and the original Places API and SDKs as Legacy. Legacy services are feature-frozen but fully supported, Google promises at least 12 months' notice before decommissioning one, and they are not available in new Google Cloud projects. We build new work on the Routes API and Places API (New), and plan the move for projects still on the older ones.

Keys, billing and quotas

Google's security guidance is to restrict every key by application (website referrer, IP address, Android package name with its SHA-1 fingerprint, or iOS bundle ID) and by API, to use a separate key for each app, and to keep server keys out of source code. Google states that you are financially responsible for charges caused by abuse of unrestricted keys, so we treat this as part of the build.

A billing account is required. Usage is billed per product and per volume, with a monthly free allowance for each; see Google's pricing page for current rates. We set budgets and quota alerts in the Cloud console, and make API calls retry with exponential backoff so a limit does not turn into a burst.

Storing results

Place IDs can be stored without time limit, but they can go stale, so we plan to refresh them. Other Places content must not be pre-fetched, cached or stored beyond the exceptions in Google's terms. Before any design that keeps results in your own database, we check it against the terms, and we recommend you do the same with your own legal advice.

How we work

Scope the location features first: what must be on the map, what people search for, and which countries and devices you support
Estimate usage and cost: a rough call volume per feature, so budgets and quotas are set before launch
Build with restricted keys: separate keys per app and per API, with alerts on usage
Hand over properly: the code in your repository, the Google Cloud project documented, and notes on where costs come from

Frequently asked questions

Do we need a Google Cloud billing account?

Yes. The Android SDK, iOS SDK and Static API pages require an API key and a project with billing enabled. Usage is charged per product, with a monthly free allowance for each. For rates, see Google's pricing page.

Should a new project use the Directions API or the Routes API?

Google lists the Directions API, the Distance Matrix API and the original Places API as Legacy, and they are not available in new Cloud projects. A new build uses the Routes API and Places API (New).

Can we store results in our own database?

Place IDs may be stored indefinitely. Other Places content must not be pre-fetched, cached or stored beyond the exceptions in Google's terms, so check the terms and your legal advice before designing storage.

How do you protect the API key?

Each key is restricted by application and by API, each app gets its own key, and server keys stay out of source code. Unrestricted keys leave you financially responsible for abuse.