Google Deprecates Their SOAP Search API

In an odd move Google has quietly deprecated their Search SOAP API, will no longer be issuing keys, and have removed the SDK from their site. They did not even issue a blog post about it. They will continue (for how long?) to support existing users, but will not do any bug fixes. They are urging developers to use their AJAX Search API ((Radar post) instead.

The AJAX Search API is great for web applications and users that want to bling their blog, but does not provide the flexibility of the SOAP API. I am surprised that it has not been replaced with a GData API instead. The developer community has been discussing this and do not seem happy with the change. Discussion on the forums have pointed out that Yahoo! has a REST Search API. Live Search also has a SOAP API available.

Not only will it be bad for Google developers, but it is bad for people trying to learn webservices. As web developer Paul Bausch wrote to us:

This is such a bad move because the Google API was *the* canonical example of how web services work. Not only is Google Hacks based on this API, but hundreds of other books and online examples use the Google API to show how to incorporate content from another site into a 3rd party application. There’s a bit of discussion about it here.

This was a unilateral move that is going to alienate at least some of the Google dev community and lead to defections to other services. The AJAX Search API is not a replacement for the SOAP API.

Update: On his blog, Nelson Minar, who wrote the original SOAP API while at Google, reflects on how this is an act of product discipline much like the recent shutdown of Google Answers (Radar post).

Update #2: Tim writes: On the other hand, SOAP has always been a political football shaped by big companies who were seeking to use it to turn web services back into a controllable software stack. (I remember the first web services summit we did, where a Microsoft developer who I won’t name admitted that SOAP was made so complex partly because “we want our tools to read it, not people.”) And it could be that innovation in web services is what we need. However, backwards compatibility is worth preserving, at least for a notice period so people can make an orderly transition. However, it sounds like they are doing that.

Update #3: Removed premature link to a blog.

Update #4: Yahoo! has pointed out that their Search APIs continue to be open for business – in REST format no less.

  • Deprecation merely means that there will be no future versions, doesn’t it ?

  • This sucks…

  • I’d celebrate the deprecation of the SOAP API if they had some alternative (say, a REST API). The AJAX API doesn’t appear to be usable by command line scripts, applications, etc.. which makes it reasonably useless judging from what I’ve seen the majority of Google Search API use to be for.

    There’ll be a replacement.. :)

  • pwb

    Good riddance.

  • FraZe

    This is nippy, as most software (clients) are now finally moving to include extensive use of web-services. Lots more websites too are using soap services, i can see the logic of using their own GData API but c’mon, who made the decision?

    Soap services are far more scalable, reusable and inter-operable than hyperlink based API’s resembling the old blog API’s. I’d like to see google desktop software use their services now (without firing up browsers in the background.

    Instead of depreciating their soap api, why don’t they make more of the things? Even split the search into 2, the 1st for common methods the 2nd for irregular ones?

    i think google are starting to lose it….

  • Matthijs

    Some way or another even the AJAX API uses HTTP to get results. That must be usable even from the command line.
    I’m not saying that this move is a good one, but we can live without the SOAP API.

    It must be possible to write a translation layer…

  • Technically, Google’s Ajax API is a fine replacement for the SOAP interface — it’s pretty RESTful and uses a decent JSON-like wire format. It’s easy to build services on, including command-line or desktop apps.

    But you’re not allowed to. The terms of service require it can only be accessed with their JavaScript library, which basically puts the UI in their hands.

  • Sadly, the google AJAX Api limits your results to 8 hits per query. While you can use refinements to get more that might be more focused, those are limited to 8 as well. The SOAP api didn’t have this limitation, which was one of the major strong points. The AJAX search is severely crippled by the limit.

  • I have a number of desktop applications that use the Google SOAP API. It is fairly functional, thus I guess it is okay if it remains as it is, as long as it keeps working. Although, I can’t understand why they don’t just replace it with a GData API. Desktop applications are still required for a lot of vertical industries.

  • Ivan

    prepare for a relaunch of the SOAP api on some sort of subscription service would be my guess.

  • Kerry

    What happened to their “Don’t be Evil” motto?

  • Trenton Lipscomb

    Matthijs says It must be possible to write a translation layer… to which S Raymond replies The terms of service require it can only be accessed with their JavaScript library.

    I skimmed their Terms of Use. The never say you must use the javascript from within a browser. Could you legally write and use a bridging layer with Rhino? I think so. (Technology-wise, it’d be quite straightforward.)

    There’s other language in the Terms which talks about the API being “limited to allowing You to host and display Google Search Results on your site” and a bunch of other stuff about not altering or replacing the responses.

    That says to me that even if you did write that bridge layer, you couldn’t change the response contents (like stripping fields). It also really sounds like you need to display the results of the query, and not store them off for later use.

    So, while a bridge layer it technically feasible, I don’t think it’d do anything for you.

  • My co-workers and I have written a drop-in replacement for Google’s SOAP service which scrapes Google’s web results and returns them via the standard SOAP interface. All you have to do is change the address your application is pointing to and you’re back in business. Enjoy!

  • Anon

    Google the next generation Microsoft without a philanthropic Bill Gates, just greedy marketers.

  • So they are evil because they are not keen to give away their product without any chance of monetisation? C’mon. While offering a backend API for free probably wont affect their potential income greatly, who can blame them for wanting to try another route?

  • Brandon K

    At some point Google has to quit giving away so many free services. This act isn’t evil, it just shows that Google is still a business and will behave like one as well. What’s good for them isn’t necessarily good for us, I’m disappointed by this announcement.

  • With Google sinking loads of money in the digitisation of our cultural heritage, I am of the opinion that their philanthropy is actually targeted really well. They do things that they understand. That gives their philanthropic investments a better return than what Bill Gates does.

    If anything I would welcome Google to spend even more money on the digitisation of books, I would be particularly grateful if they worked on the rare languages that do not have the same resources as the languages of the economic powerhouses of this world.


  • EgoWumpus

    While I agree that the digitization of our cultural heritage is not a wholly bad thing – it at the least allows access where previously that opportunity did not exist – it should not be done under the aegis of any one company; or at the least that company should not then be able to claim property over it. While Google was open and largely free, making their money as a result of our use of their tools, not as a predicate for our use of their tools, people generally felt secure with them. Any reversal of that – such as this change with the SOAP API – is going to naturally spawn a bit of caution.

  • dlib reader

    for a discussion of the issues around private sector digitization, see the recent d-lib article: Jean-Noel Jeanneney’s Critique of Google: Private Sector Book Digitization and Digital Library Policy at

  • I have no problem with Google wanting to make money. In fact, I would have been happy to pay a reasonable fee to use the SOAP API.

    It really looks like the AJAX API will not do what I need it to do, so it’s not an alternative.

  • Anonymous

    This is a great opportunity for Microsoft
    to step in and offer the same API
    functionality. Small, developer-friendly
    moves can grow into something bigger.

  • I certainly hope the API continues to function, deprecated or not. I have some server-side client software that relies on it for an internal site search feature, something I wrote both for its functionality and to demonstrate how you can convert Google’s results into valid markup (XHTML 1.1). I would prefer a REST interface, but SOAP works. There is no way I will refactor the same functionality using JavaScript/XHR. Google could take a cue from the Yahoo! Developer Network by adding features rather than taking them away. REST, JSON, serialized PHP all come to mind…

  • TGIF

    I am not trying to start a fanboy war here, but here is my experience with Google’s Search API.

    I used Google Search API in a demo project & while it was supereasy to invoke it, frankly it sucked. It kept on dropping connection with an HTTP 505 after every few calls. In addition, it limited search results based on the key in the web service.

    I moved to’s search service. They give you 10000 search results per IP (Yes, not per license key). This made it really easy to incorporate it in without bothering about hitting the limit too easily. In addition, it allows for passing in additional search criteria.

    So, I am not terribly sorry to see it go away.

  • rr

    Google has no incentive to provide a search
    api. Adwords api is what sustains its

  • Al Brown

    “Don’t be LIeVE”

  • thanks a lot. you tagged this with “flow”, which i’m finding very intriguing, because i just happen to write a paper on “micromedia interfaces” elaborating on “the flow”, but came to Linda Stone from another thread. so i’d be highly interested if you would post more about your concept of “flow” …

  • I would prefer a REST interface, but SOAP works. There is no way I will refactor the same functionality using JavaScript/XHR. Google could take ggoodd.

  • How do you reconcile that? It seems to be an obvious drive for cash dressed up as if it was a free gift and good for the community.

  • HI would prefer a REST interface. All trademarks and registered trademarks online.

  • Spacefish

    I c´mon google this definetly SUCKS! Put a XML Based API Online or something like this.. i want my C Software to query google…

  • r3n

    This decision by Google has turned me to Microsoft’s Live Search API… Now I am considering changing my homepage after a lifetime of using Google.

  • RK

    Quit whining and move to Yahoo. They are much more developer friendly.

  • Cincoranch realestate cafe riendly.

  • News google and world mega. Wil seems to be an obvious drive for cash dressed up as if it was a free gift and good for the community.

  • eu tenho um sistema de busca com as chaves ilimitadas

  • This sucks… :(

  • Put a XML Based API Online or something like this.. i want my C Software to query google…
    agree on 100%

  • Sadly, the google AJAX Api limits your results to 8 hits per query, but Google’s Ajax API is a fine replacement for the SOAP interface

  • Kalle Anka

    Google has never been developer friendly. One example of this is that you have to pay to use their Adwords API to add new ads to their systems, that you have to pay for anyway.

    Perhaps it’s because Google makes most of their money on two things, search/adwords and adsense. To grow and maintain control they first added additional cost to doing business with them, by requiring you not only to pay for the ads but also to pay for the “privilege” of automating the process (their adwords API). Now, they want to gain control over the other part of their business – search.

    They already control large parts of the search market, so the only way to grow is to force people to use their search engine so they can see ads. They don’t want Web 2.0 sites using their search engine without ads, because they lose money.

    I’m drawn more and more to Yahoo! They have always been more open, and also has better documentation.

  • Garfield

    Kalle Anka said : “I’m drawn more and more to Yahoo! They have always been more open, and also has better documentation.”

    but Yahoo too slowly to be first. Google has perfect marketing team. They not because they much more better than Yahoo or MSN, they first because everybode thinks that they better .

  • With no api keys available for Google’s soap api does anyone know where unused keys might be for sale?

    I have several clients that can’t use tools because they lost their api keys.

  • tom

    pretty soon google is going to take over the freaking world!

  • tom

    oh man, i didn’t realize this thread was over a year old. i need to just focus on the new posts.

  • Hello, as asked, key now available on ebay!

  • >>> What happened to their “Don’t be Evil” motto?

    that’s Exactly what I have been wondering since sometime back, especially when they decide to shut off the free Adwords soap service.

  • Stefanie Tellex

    I just wrote some stubs for Rhino that let you call Google Local Search without a browser. It’s very alpha and not as good as a SOAP api, but it seems to work. More details are here:

  • Stuey

    The API was fantastic but I could never use it because for some reason it returned completely different results to a standard browser search. I think this is something to do with me being outside the US but it was a right pain let me tell you. Looks like I’ll have to spend hours doing a mannual scraping program.

  • Looks like Google brought back the old SOAP API!

  • Jon P.

    SOAP sucks.

    AJAX sucks a bit less.

    Unfortunately, Google has yet to see the light and provided a REST interface to the search API instead.

  • @Jon P.,

    What are you talking about? Take a look:

    This is our new REST interface to all Google’s search properties, our feed crawler/cache, and our new language translation api.

  • anyone still have google soap api and want to sell it?