Three common meanings of “Google Maps API”
Before choosing an endpoint, identify the data or experience you need:
- Map rendering: display an interactive or static map in an app or website. Use the relevant Google Maps Platform Maps API or SDK.
- Place data: search Google’s place database, request place details, autocomplete text or retrieve photos. These are Places API capabilities.
- Maps SERP data: inspect what Google Maps search returned for a phrase and market. A SERP results API returns a snapshot of visible local results.
Google describes Places API as providing place search, autocomplete, details and photos. See the official Places API overview. Serqo’s Google Maps Results API serves the third use case and is not an official Google Maps Platform service.
Request local search results
Use the shared Serqo search endpoint with engine: "google" and type: "maps".
curl https://api.serqo.io/v1/search \
-H "x-api-key: $SERP_API_KEY" \
-H "Content-Type: application/json" \
-d '{"q":"coffee shops in Seattle","engine":"google","type":"maps","gl":"us","hl":"en"}' Local places commonly appear in data.features.localResults. Depending on the page, an item can include title, position, rating, reviews, price, category, address and placeId. Check both data.features.localResults and data.results; groups vary with the returned page. The Google Maps Results API reference documents the response and limits.
Know what it does not replace
A local-results snapshot is not an interactive map, a geocoding service, driving directions, autocomplete or a guaranteed place-details endpoint. It reports what the results page exposed for a query. If your app must let users browse a map, resolve addresses or request supported place fields by place ID, evaluate the corresponding Google Maps Platform API instead.
Choose the right tool
| Need | Use |
|---|---|
| Show a map in your app | Google Maps Platform Maps API or SDK |
| Search the Places database or request place details | Google Places API |
| Capture the local results shown for a Maps query | SERP API with Google maps type |
Frequently asked questions
Does Serqo return Google Maps results or Google Places records?
It returns extracted local results from a Google Maps search page. The fields and result groups depend on what appears for the query; it is not a full Places API response.
Can I use this to render a map or autocomplete places?
No. Use Google Maps Platform’s Maps and Places products for map rendering, autocomplete, place details and other documented capabilities.
Can I paginate Google Maps results with start?
No. The current Google maps search type does not apply start. Check the response and API reference instead of assuming web search pagination rules apply.
Start with the result you need to show
The phrase “Google Maps API” is used for several distinct tasks. If an app needs to display an interactive map, use the appropriate Maps SDK or Maps API. If it needs place lookup, autocomplete or place details, use the relevant Places API capability. If it needs to inspect the local listings visible for a Maps query, a Maps SERP API is designed for that search-result snapshot. Choosing by output prevents an API from being used for a job it does not perform.
Google's Places API overview describes its place search, details, autocomplete and photo capabilities. Serqo's Google Maps Results API returns extracted local search results and is a separate third-party service. It does not draw a map, provide a complete place database, or guarantee every field available from a Google Places response.
Request local results with a clear market
Set engine: "google" and type: "maps" on POST /v1/search. Include a query that describes the place or category, then specify a country and language that match the intended market. “Coffee shops in Seattle” and “coffee shops” with a different country context are different searches. Store the exact query and settings if you compare local visibility over time.
Do not assume that every parameter supported by Google web search also applies to maps results. Check the Google Maps API reference for supported inputs and pagination behavior. In the current Serqo implementation, Google maps does not apply the start offset. Use the fields returned by the API rather than trying to force web-search pagination onto a local-results page.
Read local result groups and optional fields
Local entries commonly appear under data.features.localResults, while other content may appear in data.results. Check both groups. A result may include a title, position, rating, review count, price range, category, address or place identifier, but the search page does not guarantee all of them. Treat ratings, counts and identifiers as optional and render only values that are present.
Keep the result's original address and place ID when returned. A displayed address may be abbreviated; it should not be treated as a verified postal address. A place identifier extracted from a search result is not a promise that every Places API operation will accept it. If your workflow requires an authoritative record or specific fields, request them from the relevant official Places service and apply its terms and billing rules.
Track local visibility responsibly
For monitoring, define the query set and market settings before collecting. Store the result position and category with the business name, URL and collection time. A listing can move, disappear or be replaced as the result page changes. Do not infer that a business closed because it was absent from one response. Confirm important changes with another source or another collection.
Comparisons need a consistent location context. Local results can depend on query wording and market, so a city-level phrase should not be compared as though it were the same request as a neighborhood or “near me” query. Serqo's API returns the result for the provided search context; it does not expose a map viewport or guarantee a specific physical searcher location.
Choose the right interface
| Need | Use |
|---|---|
| Display a map and let users pan or zoom | Google Maps Platform Maps API or SDK |
| Search official place records, autocomplete or details | Google Places API |
| Inspect local listings shown for a Maps query | SERP API with Google maps type |
Costs, limits and error handling
Successful searches use the applicable credit rate for the engine, type and country. Cache hits are free under the default rates; failed searches and timeouts release the reserved credits. A monitoring tool that checks many categories across multiple markets can multiply requests quickly. Set a deliberate schedule and measure the expected number of searches before enabling a recurring job.
Check the HTTP status and error code before parsing a success response. Keep optional properties nullable in your storage model and include the request ID in support reports. Use the Google Maps Results API reference for current fields and the pricing page for credit rules.
Common implementation mistakes
- Using a SERP result snapshot to render a map or provide turn-by-turn directions.
- Treating a missing rating or address as a search failure.
- Assuming all entries are returned under only one result group.
- Assuming a displayed address or place identifier is a complete official record.
- Comparing queries collected with different country or language settings as one series.
Keep business identity separate from result position
A local listing's displayed name is useful for a result preview, but it may not be a stable business identifier. Preserve the returned URL, address, category and place identifier where present, then use a separate matching process if your application needs to associate the listing with a business record. Avoid merging two results only because their names look similar.
If an identifier or rating is absent, keep it absent. Do not infer a missing rating from reviews or fill it from a different directory without marking the source. Users need to know whether a value came from the search result, a separate enrichment service or an internal match.
Check permissions and data use
Search result data can include content, links and business details supplied by third parties. Before storing or redistributing it, review the applicable provider terms and the rules for your own product. Keep collection purpose and retention aligned with the workflow, and avoid presenting a search snapshot as an official or complete directory.
For an application that needs users to select a place, confirm a street address or retrieve specified place fields, evaluate the official Places API. For a report about what appeared in a search, use the SERP result snapshot and explain the query context. This division keeps each interface aligned with what the data can support.
See the Google Maps Results API reference or the Google SERP API guide.