Google has publicly documented an API that does something developers have long wanted from the company: perform a full-web Google search programmatically and return the results in a structured response.
The catch is access.
Google's newly refreshed Web Search Service API documentation describes a service for “programmatic partners,” not a generally available API that any developer can enable in Google Cloud. To make a request, an organization needs a Cloud project, an API key and a designated client ID tied to a partner agreement with Google.
The timing matters because Google's older Custom Search JSON API is already closed to new customers and will be discontinued for existing customers on January 1, 2027. Google has told developers who need full-web results to contact the company about a separate full-web solution, but the public path from today's Custom Search customers to the newly documented Web Search Service remains incomplete.
Google calls it Web Search Service
The product is straightforwardly named the Web Search Service API, or WSS.
Google says it allows programmatic partners to develop websites and applications that retrieve and display Google Search results.
The service exposes one primary operation: Search.
Google's REST reference describes that method explicitly as performing a “full web search” based on the supplied request parameters.
The API returns Google Search results as structured data
Partners can call the service over REST or gRPC.
For REST integrations, successful requests return a JSON response containing search results, search metadata and a token for requesting the next page when additional results are available.
This is fundamentally different from embedding a Google search box and asking a user to interact with a hosted results page.
The developer receives structured search data that can be incorporated into an application experience subject to the partner agreement and Google's requirements.
Each request can return up to 20 results
The Search method accepts a page size between one and 20 results.
Google sets the default at 10.
If more results are available, the response can include a next-page token that the application supplies in a subsequent request.
The 20-result maximum therefore applies to a single response page rather than necessarily defining the complete number of results an approved application can navigate.
The response contains familiar search-result fields
The API is designed to return the components developers expect from web search.
Google's reference describes structured search result objects together with metadata about the search operation.
Search Engine Journal's September 12 report on the documentation notes fields including the result title, URL, snippet, MIME type and file format, along with search-level information such as timing, estimated total results and a corrected query when Google recommends one.
That gives approved partners enough structured information to build their own presentation layer around Google's results.
Country and language controls are built into the API
The request schema supports several localization parameters.
A partner can set the user-interface language, restrict results to documents written in a particular language and restrict results to documents associated with a particular country.
Those controls are important for applications serving international users because the relevant web corpus can differ substantially by market and language.
The API also accepts a region code in the user context in addition to the search-level restriction controls.
SafeSearch is configurable
Google exposes SafeSearch as an optional request setting.
The documented enum allows SafeSearch to be turned on or off.
This gives approved applications some control over the safety filtering applied to returned results rather than forcing every integration into one fixed search mode.
Applications still need to consider their own audience, moderation requirements and contractual obligations when deciding how returned content is displayed.
Date restrictions and date sorting are supported
The API can restrict search results to URLs from a specified recent period.
Google documents date filters in days, weeks, months or years.
A sort expression can also be used to order results by date.
These controls make WSS potentially useful for applications where freshness matters, such as monitoring tools, research workflows and products that need to prioritize recent web information.
Requests need more than an API key
The most important difference from a conventional public Google Cloud API is authentication and identification.
An API key identifies the Google Cloud project, but that is not enough to use Web Search Service.
Google's WSS introduction says every request is tied to a partner agreement through a ClientContext object containing a designated client ID.
The standard client ID format itself begins with a partner designation, reinforcing that this is a commercially controlled service rather than an open self-service endpoint.
The client ID connects the application to a partner agreement
Google explicitly says requests are tied to the partner agreement using the client ID.
That means copying the endpoint from the documentation and creating an ordinary Cloud API key does not give a developer access to full-web Google results.
The organization needs credentials Google has provisioned within the commercial relationship.
This access model is the central limitation behind an otherwise unusually capable web-search API.
Google also requires the end user's IP address
The REST invocation guide lists three required query components in addition to the API-key header: the partner client ID, the end user's IP address and the search query.
Google says the IP address helps with regional routing and abuse prevention.
That requirement is operationally significant for developers because it introduces privacy, architecture and compliance considerations that do not exist when a backend simply sends an application-level query without end-user network context.
Organizations evaluating WSS would need to understand the contractual and data-handling requirements associated with that field.
Pricing is not public
Google's current public WSS documentation explains how the API works technically but does not publish a price list.
That is another strong indication that access is negotiated rather than self-service.
A developer evaluating a typical public API can normally model cost from published per-request pricing before writing integration code.
With WSS, that commercial step appears to happen through the partner relationship instead.
Public query quotas are also missing
The documentation specifies how many results can be returned in an individual request, but it does not publish a general daily or monthly query quota for partners.
Those are different concepts.
A 20-result page-size maximum tells developers about response structure, not how many searches an application is contractually allowed to perform.
Until Google discloses standard quotas or a partner shares contractual terms it is permitted to disclose, developers should not assume WSS can support a particular traffic scale.
Google does not explain who qualifies as a partner
The public documentation repeatedly refers to programmatic partners but does not provide a transparent eligibility checklist.
There is no public self-service process in the WSS documentation where a developer chooses a plan, enters a credit card and immediately receives a valid partner client ID.
Search Engine Journal notes that Google has not disclosed what a company must do to become a partner.
For most developers, eligibility is therefore a bigger unknown than the API syntax itself.
The documentation was refreshed on September 9
Google's WSS overview and introduction pages show updates dated September 9, 2026, while several reference pages were updated earlier in the month.
The refreshed documentation gives the product much more public visibility at a strategically important moment.
Search Engine Journal connected that timing to Google's ongoing transition away from the Custom Search JSON API.
Google has not, however, explicitly stated in the WSS documentation that every existing Custom Search customer will be eligible to migrate to WSS.
Custom Search JSON API shuts down January 1, 2027
Google's official Custom Search JSON API documentation says the service is closed to new customers.
Existing customers have until January 1, 2027 to transition to an alternative solution.
The older API allowed applications to retrieve web and image results from a configured Programmable Search Engine in JSON format.
For current users, the approaching deadline turns the newly visible WSS documentation from a technical curiosity into a potential migration issue.
The old API had public pricing; WSS does not
The contrast between the two services is revealing.
Google still publishes the legacy Custom Search JSON API's pricing for existing customers: 100 queries per day free, with additional requests priced at $5 per 1,000 queries up to the documented daily limit.
Web Search Service provides no comparable public pricing table.
Teams cannot therefore assume that moving from Custom Search to WSS would preserve either the cost model or the usage limits of the old product.
Google distinguishes site search from full-web search
Google's transition strategy separates different search use cases.
For developers that need to search a bounded set of sites, Google points to products designed around controlled corpora and says Vertex AI Search is a suitable alternative for searching up to 50 domains.
For applications that need Google's entire web index, the Custom Search documentation tells developers to contact Google to express interest in its full-web search solution.
WSS now publicly documents a product whose Search method performs exactly that kind of full-web search.
WSS looks like the documented full-web path, but access is not guaranteed
The connection is compelling.
Google has told developers with full-web requirements that a separate solution exists, and WSS is now documented as a partner service that performs full-web searches.
But the public pages reviewed do not say that filling out the interest form automatically results in a WSS partner agreement, nor that every Custom Search JSON API customer qualifies.
The responsible interpretation is that WSS demonstrates Google's partner-only full-web capability while the exact migration and commercial access path remains undisclosed.
This matters for AI products that need web grounding
Modern AI applications increasingly need current information from the web.
A language model can answer from its training data, but products that need fresh prices, news, product details, technical documentation or recent events require retrieval infrastructure.
A structured full-web Google result feed is therefore strategically valuable for grounding, research and agent workflows.
The partner restriction means WSS is not currently a drop-in foundation for every startup building an AI search or agent product.
It could also matter for traditional search applications
Not every WSS use case needs generative AI.
Vertical search engines, research platforms, monitoring products and discovery applications can all benefit from programmatic access to broad web results.
The API's country, language, freshness and SafeSearch controls make it adaptable to several classes of search product.
The commercial agreement determines which of those uses Google actually permits for an individual partner.
REST makes the integration conceptually simple
From a developer perspective, the REST interface is familiar.
A client sends an HTTP GET request to Google's websearchservice endpoint, includes the required parameters and API-key header, and receives a JSON SearchResponse on success.
The complexity is not primarily the transport protocol.
The difficult part is obtaining the partner credentials and understanding the contractual limits that govern how the results can be used.
gRPC supports higher-performance service architectures
Google also publishes an RPC reference for the service.
The gRPC package exposes the same WebSearchService Search operation and structured request and response messages.
That gives partners an alternative to REST for systems that already use gRPC-based service infrastructure.
The presence of both interfaces suggests WSS is intended as production infrastructure rather than a lightweight experimental endpoint.
The API is not the same as scraping Google Search
Programmatic retrieval of Google results has historically pushed some developers toward unofficial scraping.
WSS is fundamentally different because it is a documented Google service with authenticated requests and an explicit partner relationship.
That provides a formal technical channel and defined response schema.
It does not make unofficial scraping equivalent or imply that developers without WSS access have permission to reproduce the same behavior through other means.
The estimated result count should not be treated as an exact census
Google's response metadata can include an estimated total number of results.
The word “estimated” matters.
Applications should avoid presenting that field as an exact count of every document Google has indexed for a query.
For most product experiences, the returned ranked results are more operationally meaningful than treating the total estimate as a precise database statistic.
Query corrections can improve search experiences
The response can also communicate query-correction information when Google recommends a different interpretation.
That is useful for applications receiving misspellings or ambiguous user input because Google's search layer can help normalize the request.
A partner can potentially use that metadata to explain why the returned results differ from the literal query.
As with all generated or inferred query handling, the user experience should make corrections understandable rather than silently changing intent in high-stakes contexts.
Pagination means developers need to manage state
When additional result pages are available, Google returns a next-page token.
The application sends that token with the subsequent Search request instead of attempting to reconstruct pagination independently.
This is a common API pattern, but it matters for caching, user navigation and distributed systems.
Developers should treat page tokens as service-provided state rather than assuming result offsets will behave like a conventional database query.
Regional routing makes end-user context part of search
The required IP address highlights an important property of web search: relevance is contextual.
The same query can produce different useful results depending on where the user is located.
Google says it uses the IP information for regional routing as well as abuse prevention, while the request also supports explicit region-related parameters.
Applications integrating WSS therefore need to think about search as a user-context operation rather than a purely server-side text lookup.
The absence of public terms limits architecture decisions
Before choosing a search provider, engineering teams normally need to know cost, throughput, latency expectations, permitted caching, result-display requirements and service-level commitments.
The public WSS technical documentation answers only part of that list.
Some of the missing information may exist in partner agreements rather than public pages.
Until a company enters that commercial conversation, it cannot responsibly assume WSS fits its economic or operational model.
Existing Custom Search users should not wait until December
The January 1, 2027 shutdown is now close enough to require concrete migration planning.
Teams should inventory where Custom Search JSON API is used, determine whether each implementation needs full-web results or only a bounded collection of sites, and evaluate replacement options accordingly.
If full-web Google results are genuinely required, Google's own documentation says to contact the company for more information about its full-web solution.
Waiting until the final weeks of 2026 risks discovering too late that partner approval, commercial negotiation or product redesign is required.
Some applications may not need full-web Google results at all
The shutdown is also an opportunity to reassess requirements.
An internal knowledge assistant may perform better with a controlled document corpus than with the entire web. A site-search product may need only its own domain. A specialized research tool may be able to combine licensed datasets and direct APIs instead.
Full-web search is powerful, but it introduces broad relevance, safety, freshness and cost considerations.
Developers should choose it because the product genuinely needs open-web retrieval, not simply because the previous API happened to provide it.
Google has revealed the technical capability, not a public product
The most important takeaway from the new documentation is the distinction between existence and availability.
Google now publicly documents a Web Search Service that can perform full-web searches, return up to 20 Google results per request, support REST and gRPC, filter by language, country and date, apply SafeSearch and expose structured result metadata.
But an API key is not enough. The service requires a designated client ID tied to a partner agreement, while public pricing, quotas and partner eligibility remain undisclosed.
That makes WSS highly relevant to the future of programmatic Google Search access without making it an open replacement for Custom Search JSON API. As the January 1, 2027 deadline approaches, developers finally have a clearer picture of Google's full-web search technology—but not yet a universal door through which they can access it.