Inhoudsopgave
De Google Places API ondersteunt het zoeken naar plaatsen, automatische aanvulling, het ontdekken van plaatsen in de buurt, bedrijfsgegevens en andere locatiegebaseerde functies. De echte uitdaging is om te bepalen welke Places-dienst het meest geschikt is voor de taak, welke velden het waard zijn om op te vragen en hoe die keuzes van invloed zijn op de kosten.
De overstap van Google naar de Places API (nieuw) verandert de manier waarop ontwikkelaars omgaan met verzoeken, veldselectie, responsgegevens en facturering. Oudere implementatiepatronen kunnen niet altijd probleemloos worden overgenomen, vooral wanneer veldmaskers en op SKU’s gebaseerde prijsstelling een rol gaan spelen.
De juiste configuratie hangt af van wat je aan het bouwen bent. Voor een locatiezoekopdracht binnen een app is wellicht slechts een beperkt aantal locatiegegevens nodig. Een team dat gebruikmaakt van de Google Places API voor het genereren van leads In veel steden kan een andere werkwijze nodig zijn. Als beide gebruikssituaties op dezelfde manier worden behandeld, kan dit onnodige kosten en extra API-werk met zich meebrengen.
Voordat je een eindpunt kiest of het maandelijkse verbruik inschat, is het handig om te begrijpen hoe Google de zoekfunctie voor Places, de veldselectie, de facturering en de quota heeft opgezet. Die afwegingen maken het ook gemakkelijker om te bepalen wanneer de officiële Places API geschikt is voor de taak en wanneer een aparte workflow voor bedrijfsgegevens zinvoller is.
Kort antwoord: Hoe de Google Places API werkt
- Zoek naar plaatsen met de tekstzoekfunctie of de zoekfunctie ‘In de buurt’.
- Bekijk details, foto’s en Place-ID’s voor specifieke locaties.
- Gebruik de functie ‘Automatisch aanvullen’ om locaties voor te stellen terwijl gebruikers typen.
- Stel een Google Cloud-project, facturering en een API-sleutel met beperkte toegang in.
- Gebruik veldmaskers om de geretourneerde gegevens en de facturering te beheren.
- De kosten zijn afhankelijk van de dienst, de gevraagde velden en het gebruik.
- Voor grote hoeveelheden bedrijfsgegevens of extra contactvelden is een andere gegevensworkflow wellicht geschikter.
Wat is de Google Places API?
De Google Places API maakt deel uit van het Google Maps Platform. Deze API biedt ontwikkelaars programmatische toegang tot informatie over bedrijven, bezienswaardigheden, adressen, geografische locaties en andere plaatsen die zijn opgenomen in de locatiedatabase van Google.
Google zegt momenteel Places API (nieuw) biedt locatiegegevens voor meer dan 200 miljoen plaatsen. Ontwikkelaars kunnen deze gegevens gebruiken om functies zoals zoeken naar plaatsen, het ontdekken van plaatsen in de buurt, automatisch aanvullen, plaatsdetails en foto’s toe te voegen aan websites, mobiele apps en andere software.
Een typisch verzoek begint met een zoekopdracht, een geografisch gebied of een bekende Place-ID. Google levert gestructureerde informatie over de locatie op basis van het type verzoek en de door de ontwikkelaar geselecteerde velden.
Een app waarmee je restaurants kunt zoeken, zou bijvoorbeeld ‘Nearby Search’ kunnen gebruiken om restaurants in de buurt van de locatie van een gebruiker te vinden. Zodra de gebruiker een restaurant heeft gekozen, kan de app ‘Place Details’ opvragen voor informatie zoals het adres, de beoordeling, de openingstijden, het telefoonnummer of recensies.
Welke gegevens kan de Google Places API retourneren?
De beschikbare velden zijn afhankelijk van het verzoek en de velden die in het veldmasker zijn opgenomen. De Places API (Nieuw) kan onder andere de volgende informatie retourneren:
| Gegevenstype | Voorbeeldvelden | Wat er wordt beschreven |
|---|---|---|
| Identiteit | Plaatsnaam, Plaats-ID, plaatstype | Geeft de locatie en de categorie ervan aan. |
| Locatie | Adres, geografische coördinaten | Geeft aan waar de locatie zich bevindt. |
| Bedrijfsgegevens | Bedrijfsgegevens, telefoonnummer, website, openingstijden | Bevat operationele en contactgegevens. |
| Klantgegevens | Beoordelingen, recensies, prijsinformatie | Biedt gegevens over beoordelingen, recensies en prijzen. |
| Media | Foto's | Geeft de beschikbare afbeeldingen weer die aan deze locatie zijn gekoppeld. |
| Toegankelijkheid | Informatie over toegankelijkheid | Beschrijft de ondersteunde toegankelijkheidsfuncties. |
| Serviceopties | Bezorging, eten in het restaurant, afhalen bij de stoep | Toont de beschikbare serviceopties, indien ondersteund. |
Google deelt deze velden in verschillende prijsniveaus in. Sommige basisvelden vallen onder goedkopere SKU’s, terwijl velden zoals beoordelingen, openingstijden en recensies aanleiding kunnen geven tot duurdere SKU’s. Google legt het verband tussen velden en facturering uit in zijn Documentatie over de gegevensvelden van de Places API. Vraag alleen de velden op die de applicatie nodig heeft, aangezien de selectie van velden de facturerings-SKU kan beïnvloeden.
De Places API (nieuw) vereist ook een veldmasker voor verzoeken van het type ‘Place Details’, ‘Text Search’ en ‘Nearby Search’. Er moet ten minste één veld worden opgegeven. Een verzoek zonder veldmasker levert een foutmelding op.
Hoe de Places API in het Google Maps Platform past
De Places API verwerkt informatie over plaatsen, maar vormt slechts een onderdeel van het Google Maps Platform.
Een ontwikkelaar kan de Places API gebruiken om een bedrijf te zoeken en vervolgens een andere dienst van het Google Maps Platform inzetten voor een andere taak. Zo kan de Geocoding API bijvoorbeeld een adres omzetten in coördinaten, terwijl routingsdiensten routebeschrijvingen of reistijden tussen locaties kunnen berekenen.
Binnen de Places API zelf zorgen de belangrijkste diensten voor verschillende onderdelen van het zoekproces naar locaties:
- Tekst zoeken zoekt locaties op basis van schriftelijke zoekopdrachten.
- Zoeken in de buurt zoekt locaties binnen een bepaald geografisch gebied.
- Locatiegegevens haalt informatie op over een bekende plaats.
- Automatisch aanvullen geeft suggesties voor plaatsen terwijl de gebruiker typt.
- Foto’s plaatsen haalt de beschikbare afbeeldingen op die bij een plaats horen.
Google raadt aan om gebruik te maken van Locatiegegevens wanneer de plaats-ID al bekend is, omdat er dan geen nieuwe zoekopdracht voor dezelfde plaats hoeft te worden uitgevoerd.
Een zoekopdracht naar bedrijven in een stad, een autocomplete-veld en een verzoek om details over één bekende locatie vereisen elk een andere methode van de Places API.
Hoe de Google Places API werkt
De Google Places API maakt gebruik van verschillende methoden, afhankelijk van de gegevens die je al hebt en het soort locatiegegevens dat je nodig hebt.
Voor een schriftelijke zoekopdracht, een set coördinaten en een bekende Place-ID is telkens een andere methode nodig. De Places API (nieuw) biedt momenteel de functies ‘Tekstzoekopdracht’, ‘Zoeken in de buurt’, ‘Plaatsdetails’, ‘Automatisch aanvullen’ en ‘Plaatsfoto’s’ voor deze taken.
Tekst zoeken
Met ‘Tekst zoeken’ kun je locaties vinden op basis van een geschreven zoekopdracht, zoals een bedrijfsnaam, categorie, adres of een zin zoals pizza in New York.
Tekstzoekfunctie (Nieuw) maakt gebruik van een HTTP POST-verzoek en retourneert overeenkomende Place-objecten. Met optionele parameters kunnen de resultaten worden verfijnd op basis van locatie, type plaats, openingsstatus, beoordeling of prijsklasse.
Google geeft momenteel maximaal 60 resultaten weer, verdeeld over alle pagina's, en wijst erop dat identieke zoekopdrachten niet altijd dezelfde lijst opleveren.
Zoeken in de buurt
Met ‘Zoeken in de buurt’ kun je plaatsen binnen een bepaald geografisch gebied vinden.
Het verzoek maakt gebruik van breedtegraad, lengtegraad en straal, en filtert vervolgens de resultaten op basis van een of meer soorten locaties. Een app zou bijvoorbeeld restaurants kunnen zoeken binnen een bepaalde afstand van een hotel.
'Zoeken in de buurt' (nieuw) maakt ook gebruik van HTTP POST en vereist een veldmasker voor de geretourneerde gegevens.
Locatiegegevens
Met ‘Plaatsgegevens’ wordt informatie over één bekende plaats opgehaald aan de hand van de plaats-ID.
Een veelvoorkomende werkwijze is:
- Zoek een plek met de tekstzoekfunctie, de zoekfunctie ‘in de buurt’ of de functie voor automatisch aanvullen.
- De Place ID behouden.
- Vraag alleen de gegevens op die de applicatie nodig heeft.
Zo wordt voorkomen dat er nogmaals wordt gezocht wanneer de locatie al is geïdentificeerd.
Automatisch aanvullen
De functie voor automatisch aanvullen geeft suggesties voor plaatsen terwijl een gebruiker in een zoekveld typt.
Een sessietoken kan de verzoeken van de gebruiker bundelen tot één zoeksessie voor factureringsdoeleinden. Voor elke nieuwe zoekopdracht moet een nieuw token worden gebruikt, en de sessie moet worden beëindigd met een compatibel verzoek voor ‘Place Details’ of ‘Address Validation’.
Locatiefoto’s en locatie-ID’s
'Place Photos' haalt afbeeldingen op die aan een plaats zijn gekoppeld wanneer de photos Het veld wordt weergegeven door ‘Tekst zoeken’, ‘Zoeken in de buurt’ of ‘Plaatsdetails’.
Plaats-ID’s identificeren specifieke plaatsen, zodat er binnen de ondersteunde diensten van het Google Maps Platform opnieuw naar kan worden verwezen.
Een app kan bijvoorbeeld via ‘Tekstzoekopdracht’ een bedrijf vinden, de Place-ID daarvan opslaan en later de Place-details opvragen zonder de oorspronkelijke zoekopdracht te herhalen.
Places API (nieuw) versus Places API (oude versie)
Google heeft de oorspronkelijke Places API op 1 maart 2025 de status ‘Legacy’ toegekend. Bestaande projecten kunnen er nog steeds gebruik van maken, maar bij nieuwe Cloud-projecten kunnen Legacy-services niet meer worden ingeschakeld.
De Places API (Nieuw) is nu de versie die Google aanbeveelt voor nieuwe ontwikkelingsprojecten. De wijzigingen hebben betrekking op verzoekmethoden, veldselectie, de structuur van de antwoorden, authenticatie en facturering.
Wat is er veranderd in de Places API (nieuw)?
Bij ‘Tekst zoeken’ en ‘Zoeken in de buurt’ wordt nu gebruikgemaakt van HTTP POST in plaats van het op GET gebaseerde patroon dat door Legacy werd gebruikt.
De Places API (nieuw) ondersteunt ook API-sleutels en OAuth, retourneert JSON-antwoorden en vereist veldmaskers voor ‘Place Details’, ‘Text Search’ en ‘Nearby Search’.
Find Place heeft geen directe nieuwe versie. Google leidt dergelijke zoekopdrachten door naar Text Search.
Veldmaskers en wijzigingen in reacties
Veldmaskers vormen een van de belangrijkste verschillen tussen de Places API (nieuw) en de oudere API.
Voor ‘Plaatsdetails’, ‘Tekstzoekopdracht’ en ‘Zoeken in de buurt’ moet in het verzoek ten minste één veld worden opgegeven dat moet worden geretourneerd. Als het veldmasker wordt weggelaten, mislukt het verzoek.
De veldselectie heeft ook invloed op de facturering, omdat Google veldgegevens over locaties aan verschillende SKU’s toewijst. In het gedeelte over prijzen verderop in dit artikel wordt die relatie nader toegelicht.
Ook de responsobjecten zijn gewijzigd. De Places API (nieuw) maakt gebruik van veldnamen in camelCase in plaats van de vele snake_case-namen die in de oude responsen voorkomen.
Voorbeelden hiervan zijn:
opgemaakt_adreswordtopgemaaktAdresbusiness_statuswordtbedrijfsstatusopgemaakt_telefoonnummerwordtnationaal telefoonnummergeometrie.locatiewordtlocatie
Ook ‘Tekst zoeken’ en ‘Zoeken in de buurt’ geven resultaten weer in een plaatsen array in plaats van de Legacy resultaten array. Status- en foutinformatie maakt nu gebruik van standaard HTTP-responscodes en -berichten in plaats van verouderde velden zoals status en foutmelding.
Deze wijzigingen zijn van belang wanneer bestaande applicaties Legacy-antwoorden verwerken of gebruikmaken van oudere veldnamen.
Wat gebruikers van de Legacy API moeten weten over de migratie
Voor een migratie is meestal meer nodig dan alleen het wijzigen van het eindpunt. Google biedt een Handleiding voor de migratie van de Places API waarin de belangrijkste verschillen tussen de Legacy API en de Places API (nieuw) worden behandeld.
Controleer eerst de volgende punten:
- Verplaats de zoekopdrachten voor ‘Plaats zoeken’ naar ‘Tekst zoeken (nieuw)’.
- Wijzig de verzoeken voor ‘Tekst zoeken’ en ‘Zoeken in de buurt’ van GET naar POST.
- Voeg de vereiste veldmaskers toe.
- Werk de code bij die de oude responsvelden uitleest.
- Controleer de SKU die bij elk verzoek is gebruikt.
Controleer ook of de Places API (Nieuw) in het project is ingeschakeld en of dit is toegestaan volgens de beperkingen van de API-sleutel.
Als verzoeken van het oude systeem en nieuwe verzoeken tijdens het testen tegelijkertijd moeten worden uitgevoerd, houd de twee verwerkingsstromen dan gescheiden. Google raadt aan om tijdens de migratie afzonderlijke API-sleutels te gebruiken.
Bestaande Legacy-integraties kunnen voorlopig blijven draaien, maar bij nieuwe projecten moet de Places API (nieuw) worden gebruikt.
Handleiding voor de Google Places API: installatie en je eerste verzoek
Om de Places API (nieuw) te kunnen gebruiken, moet je eerst een Google Cloud-project koppelen aan een factureringsaccount. De Places API (nieuw) moet voor het project zijn ingeschakeld voordat je geauthenticeerde verzoeken kunt verzenden.
Voor een eenvoudig webserviceverzoek bestaat de installatie uit vijf stappen: kies een Cloud-project, schakel de API in, maak een API-sleutel aan, beperk de sleutel en verstuur een verzoek met de velden waarvan je de resultaten wilt ontvangen.
Een Google Cloud-project aanmaken of selecteren
Elk verzoek aan het Google Maps Platform hoort bij een Google Cloud-project.
U kunt een nieuw project aanmaken of een bestaand project gebruiken. Het geselecteerde project moet ook een actief factureringsaccount hebben. Google gebruikt het project om de API-toegang, het gebruik, de quota en de kosten bij te houden.
Het kan ook zinvol zijn om projecten gescheiden te houden wanneer ontwikkel-, test- en productieomgevingen verschillende inloggegevens of gebruiksbeperkingen vereisen.
Zodra het juiste project is geselecteerd, kan de Places API (Nieuw) worden ingeschakeld via de Google Cloud Console.
Places API inschakelen (nieuw)
De Places API (nieuw) moet voor het project zijn ingeschakeld voordat de applicatie de webservicemethoden ervan kan aanroepen.
In de Google Cloud Console:
- Selecteer het project dat u wilt gebruiken.
- Openen API's en diensten.
- Zoeken Places API (nieuw) in de API-bibliotheek.
- Schakel deze functie in voor het project.
Dit onderscheid is van belang voor oudere projecten, omdat de Places API (Legacy) en de Places API (New) afzonderlijke diensten zijn. Bij een project dat voorheen de Legacy API gebruikte, moet de Places API (New) mogelijk nog worden ingeschakeld voordat nieuwere eindpunten werken.
Instellen van API-sleutels en beperkingen
Een API-sleutel identificeert het Google Cloud-project dat het verzoek indient.
Google vereist dat facturering is ingeschakeld voordat de Places API (Nieuw) kan worden gebruikt voor live verzoeken. Als je alleen het installatieproces volgt en nog geen factureringsaccount wilt koppelen, kun je stoppen voordat je de sleutel aanmaakt en later terugkeren naar deze stap.
Als facturering is ingeschakeld, maak dan een API-sleutel aan in de Google Cloud Console en beperk de toegang ervan voordat u deze in een applicatie gebruikt.
Bij server-side Places API-verzoeken kan een IP-adresbeperking ervoor zorgen dat de sleutel alleen op goedgekeurde servers kan worden gebruikt. Je kunt de sleutel ook zo beperken dat deze alleen werkt met de Places API (Nieuw) en andere Google Maps Platform-services die de applicatie daadwerkelijk nodig heeft.
Google vereist bovendien dat verzoeken aan de Places API-webservice via HTTPS worden verzonden. Een ontbrekende sleutel, een onjuiste beperking of een niet-ondersteunde configuratie kan leiden tot een REQUEST_DENIED antwoord.
Voorbeelden van de Google Places API: je eerste zoekopdracht op tekst uitvoeren
'Tekst zoeken' is een eenvoudig voorbeeld van de Google Places API om inzicht te krijgen in het verzoekformaat, de API-sleutel in de header en het veldmasker.
De Places API (nieuw) verstuurt zoekverzoeken op tekst naar:
https://places.googleapis.com/v1/places:searchText
Het verzoek maakt gebruik van HTTP POST. De zoektekst wordt in de JSON-body geplaatst, terwijl de API-sleutel en het veldmasker via de verzoekheaders kunnen worden verzonden.
Een eenvoudig verzoek kan er als volgt uitzien:
curl -X POST \
-H "Content-Type: application/json" \
-H "X-Goog-Api-Key: YOUR_API_KEY" \
-H "X-Goog-FieldMask: places.id,places.displayName,places.formattedAddress" \
-d '{ "textQuery": "dentists in Chicago" }' \
"https://places.googleapis.com/v1/places:searchText"
Met deze zoekopdracht wordt gezocht naar dentists in Chicago en vraagt Google om alleen het volgende weer te geven:
- Plaats ID
- weergavenaam
- opgemaakt adres
Een succesvolle reactie retourneert overeenkomende Place-objecten binnen een places array. Welke velden in elk resultaat worden opgenomen, hangt af van het veldmasker dat in het verzoek is gebruikt.
Door een masker met een beperkt veld te gebruiken, blijft de respons overzichtelijker en wordt voorkomen dat er gegevens worden opgevraagd die de applicatie niet nodig heeft.
Raadpleeg de officiële pagina voor de huidige verzoekparameters, ondersteunde velden, quota’s en API-wijzigingen. Documentatie over de Google Places API.
Voorbeeld van de Google Places API: gegevens van een locatie ophalen
Een reactie op een tekstzoekopdracht kan voor elke overeenkomende locatie een plaats-ID opleveren. Zodra de applicatie het plaats-ID kent, kan deze met behulp van ‘Plaatsdetails’ informatie over die specifieke plaats opvragen zonder opnieuw te hoeven zoeken.
Het verzoek volgt dit patroon:
https://places.googleapis.com/v1/places/PLACE_ID
Bijvoorbeeld:
curl -X GET -H "Content-Type: application/json" -H "X-Goog-Api-Key: YOUR_API_KEY" -H "X-Goog-FieldMask: id,displayName,formattedAddress" "https://places.googleapis.com/v1/places/PLACE_ID"
Replace PLACE_ID with the ID returned by Text Search, Nearby Search, or another supported Places method.
Notice that the Place Details field mask uses id, displayNameen formattedAddress rather than places.id, places.displayNameen places.formattedAddress. Place Details returns one Place object, while Text Search returns Place objects inside a places array.
Choose the Fields You Need
Place Details, Text Search, and Nearby Search require a field mask in Places API (New). If no field is specified, the request returns an error.
For Text Search, a field mask might look like:
places.displayName,places.formattedAddress
If the application also needs a website and rating, the field mask can be expanded:
places.displayName,places.formattedAddress,places.websiteUri,places.rating
Google also supports * as a wildcard for all available fields, but it discourages using the wildcard in production. Requesting unnecessary fields can increase the amount of returned data and move the request into a higher billing SKU.
Keep the field mask limited to the data the application actually uses. Field selection affects both the response and the request cost.
The pricing section below explains how those field choices map to Google Places API SKUs.
Use Outscraper Google Maps-krabber to collect business data through a no-code workflow without setting up individual Places API requests.
Google Places API Pricing and Free Usage
Google Places API uses pay-as-you-go pricing. Each request is billed under a specific SKU, and the cost depends on the method used, the fields requested, and the number of monthly billable events.
Google no longer uses the old recurring $200 Maps Platform credit. The current model gives each SKU its own monthly free usage cap. Those caps reset at the start of each month.
How Google Places API SKUs Work
A SKU is the billing category attached to a Places API request.
Places API (New) divides many requests into pricing levels such as Essentials, Pro, and Enterprise. The fields requested can move a request into a higher-priced SKU.
For example, Place Details can be billed under different SKUs depending on the requested fields:
- Place Details Essentials includes a monthly free usage cap of 10,000 events.
- The monthly free usage cap for Place Details Pro is 5,000 events.
- For Place Details Enterprise, the monthly free usage cap is 1,000 events.
After the free usage cap, pricing is applied per 1,000 events and becomes lower at higher monthly volumes.
Text Search and Nearby Search follow a similar structure.
For the first paid usage tier, Google currently lists the following rates on the official Google Maps Platform pricing page:
*These figures are for the first pricing tier shown on Google's global pricing page. Higher monthly volumes use lower per-1,000 rates.
Google also offers some IDs-only SKUs with unlimited free usage, including Place Details Essentials (IDs Only) and Text Search Essentials (IDs Only).
Current Free Usage Caps
Free usage is attached to individual SKUs rather than to one shared dollar credit.
Bijvoorbeeld:
- Autocomplete Requests: 10,000 free monthly events
- Place Details Essentials: 10,000
- Place Details Pro: 5,000
- Text Search Pro: 5,000
- Nearby Search Pro: 5,000
- Place Details Enterprise: 1,000
- Text Search Enterprise: 1,000
- Nearby Search Enterprise: 1,000
Some IDs-only services have unlimited free usage.
This makes cost estimates more dependent on the exact request than under the older credit system. Two applications making the same number of Places API calls can have different bills if they request different fields or use different methods.
How Requested Fields Affect Billing
Field masks control more than the size of the response.
For Place Details, Text Search, and Nearby Search, Google bills the request according to the highest SKU represented by the requested fields. If the field mask includes fields from both Essentials and Pro, the request is billed at the Pro level.
For example, an application that only needs a Place ID and address may not need the same fields as one requesting ratings, opening hours, reviews, and additional place attributes.
This makes field selection part of the cost calculation.
Avoid requesting every available field by default. Start with the fields required by the feature and add others only when they serve a clear purpose.
How Autocomplete Sessions Affect Billing
Autocomplete can be billed per request or as part of a session.
Without a session token, each Autocomplete request is billed separately under the Autocomplete Requests SKU.
A session groups a user’s Autocomplete requests with the request that completes the selection. A typical session begins with one or more Autocomplete calls and ends with Place Details (New) or Address Validation. Each new user search should use a new session token.
For sessions that end with Place Details Essentials, Google currently bills the first 12 Autocomplete requests individually. Requests after the 12th are billed under Autocomplete Session Usage, which has no charge. The terminating Place Details request is still billed under its own SKU.
Abandoned sessions do not receive that session treatment. If the user never completes the session with Place Details or Address Validation, the Autocomplete calls revert to per-request pricing.
How to Estimate Google Places API Costs
A useful cost estimate starts with the actual request flow rather than the total number of users.
Check:
- Which Places API method will be called.
- How many times the method is called during one user action.
- Which fields are included in the field mask.
- Which SKU those fields trigger.
- How many billable events are expected each month.
- How much of that usage falls inside the SKU’s free monthly cap.
- Whether Autocomplete requests are grouped into properly completed sessions.
For example, an application making 20,000 monthly Place Details Essentials requests would first use the 10,000-event monthly free cap. The remaining 10,000 events would fall into the paid pricing tier.
At the current first-tier rate of $5 per 1,000 events, those 10,000 paid requests would cost about $50 before taxes or any other Maps Platform usage is included.
The calculation changes if the field mask triggers a Pro or Enterprise SKU, so the expected fields should be part of the cost estimate from the beginning.
When Google Places API Is and Isn't the Right Tool
Google Places API works well when place information is part of an application feature. A search box, store locator, travel app, delivery interface, or nearby-business feature can request place information when the user needs it.
The requirements change when the main goal is building a business dataset. Collecting records across many categories, cities, or regions is a different workflow from looking up places inside an application.
For a deeper comparison of official API access and large-scale data extraction, see Google Maps API vs. web scraping.
When Google Places API Works Well
Google designed Places API (New) around location-aware application features.
It is a strong fit when an application needs to:
- search for places from user input
- find nearby businesses or points of interest
- suggest places while someone types
- retrieve details about a known place
- display place photos
- use Place IDs across supported Google Maps Platform services
For example, a hotel-booking app could show restaurants near a selected property. A delivery app could use Autocomplete to help a customer enter a destination. A store locator could retrieve details about a specific branch after the user selects it.
These requests usually happen as part of an interaction inside the application. The developer controls which method is called, which fields are returned, and how the results appear to the user.
Google’s documentation describes Places API (New) around these types of place search, lookup, autocomplete, and location-aware application features.
When You Need Business Data in Bulk
Some projects need a dataset rather than a place-search feature.
Instead of asking:
Welke restaurants zijn er in de buurt van deze gebruiker?
a research team may need:
Welke restaurants zijn er in deze 50 steden te vinden?
The same pattern appears across different teams:
- Ontwikkelaars may need place search or details inside an application.
- Marketeers may need businesses by category and location for market research.
- Sales teams may need business records that match geographic or company criteria.
- Data professionals may need structured records for analysis, dashboards, or internal systems.
When the work involves collecting hundreds or thousands of business records, the process shifts from individual place lookup to data collection.
For market research, see what Google Maps business data to collect for market analysis before deciding which fields belong in your dataset.
A No-Code Option for Business Data Collection
Teams that do not need to build a place-search feature can use Outscraper Google Maps-krabber to collect business records without setting up Google Cloud requests or writing API code.
Users can search by category and location, run the collection through the web interface, and export the results for research, prospecting, or analysis.
For developers and data teams that need programmatic access, Outscraper Google Maps Places API is a separate service from Google’s Places API (nieuw). It supports bulk business-data collection. See the Outscraper API Docs for request details.
An application that needs nearby place search has a different data requirement from a team building a reusable business dataset.
Use Outscraper Google Maps Places API when you need business records across multiple categories or locations for research, sales, analysis, or another data workflow.
When You Need Additional Business or Contact Data
Google Places API can return addresses, phone numbers, websites, ratings, reviews, opening hours, business status, and other place fields.
For prospecting or market research, that may still leave gaps. Teams may also need email addresses, contact details, social profiles, or other company information before a record is ready to use.
If you need to add contact and company information after collecting place data, see the guide to Verrijking van gegevens in Google Maps Places.
A typical workflow is:
- Find businesses by category and location.
- Keep the fields needed for targeting.
- Add contact or company data.
- Export the records for sales, research, or another system.
Outscraper supports business-data collection through both no-code and API workflows, with additional enrichment options for emails, contacts, and social profiles.
Google Places API fits place search and place details inside applications. Business-data workflows that need contact data, enrichment, or export usually require additional tools.
Google Places API Limits, Quotas, and Billing Risks
A Places API setup can work in testing and still run into cost, quota, or access problems once usage increases.
Google applies quotas by API method and project rather than through one shared daily limit. Usage, quotas, errors, and billing can be checked in Google Cloud Console.
Request Only the Fields You Need
Field masks affect both the response and the billing SKU.
If a request includes Pro-level fields, Google can bill the request at the Pro rate even when lower-cost fields are also included. Keep the field mask limited to data the application actually uses.
Use the Right Search Method
Text Search works from a written query. Nearby Search works from a defined geographic area and place-type criteria.
Bijvoorbeeld:
coffeeshops in Bostonfits Text Search.- restaurants within a set radius fit Nearby Search.
Choosing the right method reduces unnecessary requests and extra filtering.
Manage Autocomplete Sessions Correctly
Autocomplete can generate several requests while a user types.
Use a new session token for each search session and complete the session with a compatible Place Details or Address Validation request. Abandoned or incorrectly configured sessions can be billed as separate requests.
Keep Legacy and New Requests Separate
Places API (Legacy) and Places API (New) use different request formats, field names, and response structures.
Do not mix Autocomplete session tokens between Legacy and New requests. Check older integrations before moving production traffic to Places API (New).
Restrict Your API Keys
Google recommends restricting API keys by application and API.
For server-side requests, IP restrictions can limit where the key is used. API restrictions can limit the same key to Places API (New) and other required services.
An incorrectly configured key can also cause VERZOEK_AFGEWEZEN errors, so restrictions should be tested before production use.
Set Quotas and Billing Alerts
Google Cloud Console can track traffic, errors, quotas, and spending.
Set quota limits and billing alerts before request volume grows. Billing alerts warn you when spending reaches selected thresholds, but they do not automatically stop API usage.
Final Checklist: Before You Use the Google Places API
- Choose the Places API method that matches the task.
- Use Places API (New) and request only the fields you need.
- Check the SKU, free usage cap, and expected monthly cost.
- Restrict the API key and set quotas or billing alerts.
- Decide whether you need app-based place lookup or bulk business-data collection.
Gebruik Outscraper Google Maps Places API to collect business records across multiple locations or categories.
FAQ
Meest voorkomende vragen en antwoorden
De Google Places API is niet volledig gratis. Google hanteert een pay-as-you-go-tariefstructuur met maandelijkse limieten voor gratis gebruik per afzonderlijke SKU. Zo omvatten bijvoorbeeld ‘Autocomplete Requests’ en ‘Place Details Essentials’ momenteel 10.000 gratis gebeurtenissen per maand, terwijl andere SKU’s lagere limieten hebben.
De Places API wordt gebruikt om naar plaatsen te zoeken en informatie op te halen over bedrijven, bezienswaardigheden en andere locaties. De Geocoding API wordt voornamelijk gebruikt om adressen om te zetten in coördinaten of coördinaten weer om te zetten in adressen. Beide API’s kunnen met Place-ID’s werken, maar ze zijn bedoeld voor verschillende taken op het gebied van locatiegegevens.
De Places API levert gegevens over locaties via HTTP-verzoeken. De Maps JavaScript API wordt gebruikt om interactieve kaarten en browsergebaseerde kaartfuncties aan websites toe te voegen. De bijbehorende Places Library biedt bovendien de mogelijkheid om binnen een webapplicatie naar locaties te zoeken en automatisch aan te vullen.
Ja. Voor een Places API-productieproject is een Google Cloud-project nodig dat is gekoppeld aan een factureringsaccount. Daarnaast moet voor het project de vereiste Places API-service zijn ingeschakeld en moet het beschikken over geldige authenticatiegegevens.
Een Place-ID is een tekstuele identificatiecode voor een locatie in de Google Places-database en Google Maps. Deze kan worden gebruikt in verschillende diensten van het Google Maps Platform, waaronder de Places API, de Geocoding API, de Maps JavaScript API en de Routes API. Google wijst erop dat Place-ID’s in de loop van de tijd kunnen veranderen en raadt aan om opgeslagen ID’s die ouder zijn dan 12 maanden te vernieuwen.
De Places API (Nieuw) is de huidige versie voor nieuwe ontwikkelingen. Sommige Legacy-methoden komen rechtstreeks overeen met nieuwere methoden, terwijl andere zijn gewijzigd. Zo vervangt bijvoorbeeld ‘Text Search (Nieuw)’ de methode ‘Find Place (Legacy)’. Bestaande Legacy-projecten worden nog steeds ondersteund, maar bij nieuwe Cloud-projecten kunnen Legacy-services niet worden ingeschakeld.
In de huidige lijst met veldgegevens van de Places API (Nieuw) van Google komt geen veld voor zakelijke e-mailadressen voor. De API kan velden zoals telefoonnummers en website-URL’s retourneren, maar zakelijke e-mailadressen staan niet vermeld als ondersteund veld voor Places.
