Google Places API
google_places
95% off
Find businesses and points of interest with country, location, language, and pagination controls.
Selected API: Google Places API — Search Google Places and return normalized local results.
Search Google Places with optional country, city, language, and page controls. APINEED returns a stable list of local results instead of exposing the supplier response.
APIS1PRICE$0.00125 per requestRESPONSEStructured JSON
{
"request_id": "example_google_places",
"tool": "google_places",
"output": {
"page": 1,
"places": [
{
"address": "San Francisco, CA",
"position": 1,
"title": "Coffee Shop",
"type": "Coffee shop"
}
],
"query": "coffee"
},
"usage": {
"price_usd": "0.00125",
"quota": 625
}
}Google Places API Pricing
Current pricing from the APINEED catalog. Failed requests are refunded; server usage records remain authoritative.
Quick Start
Invoke Google Places with one APINEED key and a JSON request body.
Use your APINEED API key
Reuse the same APINEED API key that your application already uses for LLM, image, and video APIs. Keep it server-side.
Create API keyexport API_NEED_API_KEY=sk-apineed-v1-...Send the request
POST the same input shown in the Playground to /v1/tools/google_places/invoke.
curl 'https://apineed.com/v1/tools/google_places/invoke' \
-H "Authorization: Bearer $API_NEED_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"country": "us",
"language": "en",
"location": "San Francisco, California, United States",
"page": 1,
"query": "coffee"
}'Read the response
Use output.places for the result and usage.price_usd for the settled request price.
const places = response.output.places;Endpoint
This endpoint uses bearer-token authentication and returns a synchronous normalized JSON response.
POST
/v1/tools/google_places/invoke- Authorization
- Bearer $API_NEED_API_KEY
- Content-Type
- application/json
- Billing
- $0.00125 per request on successful invocation
- Response
- request_id, tool, output, usage
Google Places API Parameters
Only query is required. country, location, language, and page are optional and are omitted upstream unless supplied.
| Name | Type | Requirement | Values | Description |
|---|---|---|---|---|
query | string | Required | 1–500 characters | The Places search query. |
country | string | Optional | Pattern: ^[A-Za-z]{2}$ | Optional two-letter country code. |
language | string | Optional | Pattern: ^[A-Za-z]{2,3}(-[A-Za-z]{2,4})?$ | Optional result language. |
location | string | Optional | 1–500 characters | Optional human-readable location. |
page | integer | Optional | 1–100 | Optional results page number. |
Google Places API Introduction
One collection page for the related APIs, with a developer guide for the currently selected request contract.
Google Places API overview
Google Places API is a JSON interface for finding businesses and points of interest from a text query with country, human-readable location, language, and page controls. APINEED presents it as a tool: an application sends a bounded request, receives a stable envelope, and uses the same key, balance, and usage records as model traffic. It fits server products, agents, pipelines, dashboards, and scheduled jobs that need structured data. It is an APINEED normalized place-search tool, not the official Google Places API (New), and its schema, key, endpoint, price, and response differ from Google Maps Platform. The live catalog publishes the endpoint, price, schemas, example payload, and limits together. Start with the smallest valid request, verify the response, and add optional controls only when the product needs them. This keeps a Google Places API integration observable and avoids assumptions borrowed from a different service.
Designing a Google Places API request
Send the Google Places API request as JSON to /v1/tools/google_places/invoke with an APINEED bearer key. The required query names a business, category, or place need. Optional country is a two-letter code, location is a human-readable area, language localizes results, and page selects pages 1 through 100. The endpoint intentionally does not accept undocumented official-API fields. Unknown top-level fields are rejected so typos fail clearly instead of being ignored. Omitted values keep documented defaults, while explicit zero or false values remain meaningful. Validate types, enums, ranges, and pagination before sending traffic. Store the key on the server; never place it in a browser bundle, URL, analytics event, or log. The signed-in Playground tests through the website session without exposing a key. In production, set a timeout, attach a correlation ID, and retain request_id so a Google Places API call can be reproduced and investigated.
Reading the Google Places API response
A successful Google Places API call returns request_id, tool, output, and usage. request_id identifies the operation, output contains tool data, and usage records the settled dollar price and quota. output.query and output.page retain request context and output.places contains normalized place candidates. Title is required; address, latitude, longitude, rating, rating_count, price_level, type, types, website, phone_number, description, opening_hours, thumbnail_url, cid, fid, and place_id can be absent. Treat optional output fields as optional: an empty array may be valid, missing text must not break parsing, and numeric units should be preserved. Store request_id with downstream records and read the final charge from usage rather than duplicating billing math. On failure, inspect the HTTP status and public error code instead of parsing the body as success. Retry only transient failures. A typed response boundary lets the application tolerate variation without discarding useful fields.
Interpreting Google Places API data correctly
Interpretation is often harder than transport. Google Places API data can be valid yet unsuitable for a conclusion when geography, language, time range, ranking context, sampling, freshness, or missing fields are ignored. A place result is a candidate listing matched to text and location context. Similar names can refer to different branches, ratings are time-sensitive, categories can be broad, and a place identifier is more useful than a title alone when the application needs continuity. Store the request controls and retrieval time beside the response. Do not turn a preview, rank, score, count, or label into a stronger claim than it supports. For customer-facing answers, verify an underlying source where possible and distinguish observation from inference. Repeated Google Places API calls may change, so decide whether the workflow needs live data, a cached snapshot, or a dated record. These rules keep convenient JSON from being treated as unquestionable evidence. [1][2]
Google Places API workflows and use cases
Use Google Places API as one explicit step in a larger workflow. Use it for business discovery, travel planning, store or restaurant search, location-aware agents, lead research, and letting a user choose one place before a later action. Display enough address and category context to prevent selecting the wrong branch. For an agent, define when it may call the tool, which user input is copied, how many items are allowed, and which fields enter model context. A pipeline should retain the request, execution time, request_id, and normalization version. A dashboard should show relevant market, language, period, or location controls. Monitoring jobs should deduplicate repeated items and alert on meaningful change. Start with one measurable use case and test positive, empty, localized, malformed, and rate-limited requests before expanding access. Retrieval belongs to Google Places API; ranking, policy, summarization, and user experience remain application responsibilities.
Accuracy, freshness, and limits of Google Places API
Do not treat Google Places API as an unlimited or permanent database. The response is not guaranteed to contain live inventory, bookings, directions, verified ownership, accessibility details, or every contact field. A listing can move, close, merge, or change identifiers, so critical actions require fresh confirmation. Results can change when a page is re-ranked, a place changes, a topic cools, or an optional field disappears. The APINEED schema defines accepted and normalized data; it does not promise a maximum item count or every optional attribute. Handle empty and partial results from the first release. Cache only when staleness is acceptable and store a retrieval time. Google Places API can assist discovery for sensitive legal, medical, financial, safety, or compliance work, but it should not be the only authority. Document blind spots and let users inspect material conclusions. [1][2]
Production reliability for Google Places API
A production Google Places API client needs bounded concurrency, timeouts, jittered backoff, and a retry budget. Never retry validation or authentication failures. Retry a timeout or temporary dependency failure only when the call is safe and still useful. Record latency, status, public error code, request_id, and settled usage, while redacting credentials and sensitive query text. Test exact business names, broad categories, duplicate chains, country and location combinations, localized language, page bounds, places with sparse metadata, optional IDs, international phone formats, and safe handling of returned links. Contract tests should cover required fields, explicit zero or false values, maximum lengths, pagination boundaries, empty output, and representative optional fields. A low-frequency canary may detect a dependency outage, but it should not create unnecessary billable traffic. These controls prevent one delayed Google Places API dependency from producing duplicated work.
Billing, rate limits, and caching
The live catalog publishes the current Google Places API price; do not hardcode it. A successful response includes usage.price_usd and usage.quota, while usage logs provide reconciliation. Let server settlement decide failed-call billing. Rate limits protect users and shared capacity, so pace bursts, honor Retry-After when supplied, and prevent synchronized worker retries. Use conservative expirations for opening hours, ratings, and contact information. Include query, country, location, language, and page in the key, and store the retrieval time so the UI can communicate freshness. A cache key must include every result-shaping parameter, use an explicit expiration, and keep sensitive input out of shared namespaces. Catalog pricing, bounded retries, and intentional caching make Google Places API cost predictable without trading correctness for a lower request count.
Google Places API Q&A
One shared Q&A for the API group, covering selection, interpretation, authentication, billing, rate limits, and production use.
What does Google Places API do?
Search Google Places with optional country, city, language, and page controls. APINEED returns a stable list of local results instead of exposing the supplier response.
How do I authenticate?
Send a POST request to /v1/tools/google_places/invoke with your APINEED API key in the Authorization: Bearer header. The same key can be used for model APIs. Keep the key on your server, not in browser code.
Can I try this API without entering an API key?
Yes. The Playground uses your signed-in APINEED account and shared balance. Sign in to send a request, or add funds if your balance is insufficient.
Which input fields are required?
Required fields: query. Check the parameter table for types, allowed values, and limits.
Can I omit optional parameters?
Yes. Optional fields: country, language, location, page. Omitted fields are not sent. Explicit false and 0 values are preserved; use the defaults and limits documented in the parameter table.
How much does a request cost?
The current catalog price is $0.00125 per request. The final charge is recorded in usage.price_usd and your account usage logs. Failed requests are refunded.
How should I read the response?
A successful invocation returns request_id, tool, output, and usage. Read the result from output, preserve request_id for troubleshooting, and inspect usage for the settled charge. The Playground shows the returned JSON without changing it.
What is the APINEED Google Places API?
APINEED Google Places API is a server-side JSON tool for finding businesses and points of interest from a text query with country, human-readable location, language, and page controls. It shares the APINEED key, balance, usage logs, and error envelope. The live Google Places API schema defines supported requests and responses.
Is Google Places API an official Google API?
No. APINEED Google Places API is not an official Google product. It is an APINEED normalized place-search tool, not the official Google Places API (New), and its schema, key, endpoint, price, and response differ from Google Maps Platform. Integrate against the APINEED endpoint and schema; use Google documentation only for claims about Google products or data interpretation. [1][2]
Which fields are required by Google Places API?
The required query names a business, category, or place need. Optional country is a two-letter code, location is a human-readable area, language localizes results, and page selects pages 1 through 100. The endpoint intentionally does not accept undocumented official-API fields. The live parameter table lists required flags, types, enums, patterns, and bounds. Unknown top-level fields are rejected so a Google Places API client receives a clear validation error.
What does Google Places API return?
output.query and output.page retain request context and output.places contains normalized place candidates. Title is required; address, latitude, longitude, rating, rating_count, price_level, type, types, website, phone_number, description, opening_hours, thumbnail_url, cid, fid, and place_id can be absent. A successful Google Places API call also includes request_id, tool, output, and usage. Keep request_id for support and use usage.price_usd as the settled charge.
How should I interpret Google Places API results?
A place result is a candidate listing matched to text and location context. Similar names can refer to different branches, ratings are time-sensitive, categories can be broad, and a place identifier is more useful than a title alone when the application needs continuity. Preserve request controls and retrieval time, tolerate missing optional fields, and do not treat a rank, relative score, preview, or category from Google Places API as a stronger fact than its source supports. [1][2]
Can I use Google Places API with AI agents or RAG?
Yes. Use it for business discovery, travel planning, store or restaurant search, location-aware agents, lead research, and letting a user choose one place before a later action. Display enough address and category context to prevent selecting the wrong branch. Keep each Google Places API call bounded, treat returned text as untrusted, verify important sources, and pass only necessary fields into model context.
Are failed Google Places API requests billed?
Use APINEED settlement and usage logs as the billing record. Do not create a client-side charge after a failed Google Places API call. Retry only transient failures with a bounded budget.
How should I handle Google Places API rate limits?
Pace bursts, bound concurrency, honor Retry-After when supplied, and use jittered backoff. Do not retry invalid input or authentication failures. Coordinate workers sharing Google Places API through a queue or limiter.
Can Google Places API responses be cached?
Yes, when the freshness window is acceptable. Use conservative expirations for opening hours, ratings, and contact information. Include query, country, location, language, and page in the key, and store the retrieval time so the UI can communicate freshness. Include every result-shaping Google Places API parameter in the key, store retrieval time, set an expiration, and keep sensitive input out of shared caches.
What limitations should I test before launch?
The response is not guaranteed to contain live inventory, bookings, directions, verified ownership, accessibility details, or every contact field. A listing can move, close, merge, or change identifiers, so critical actions require fresh confirmation. Test Google Places API empty results, missing fields, localization, maximum lengths, pagination, timeouts, rate limits, and representative production queries. Do not assume another API’s fields are supported. [1][2]
What is the safest way to migrate to Google Places API?
Compare both paths with a fixed evaluation set, log request_id and latency in a small canary, move traffic gradually, keep rollback, and update clients from the published Google Places API schema.