Deep Green Crystals

“You agree that you will not, and will not assist or enable others to:

1. cache, record, pre-fetch, or otherwise store any portion of the Groupon Content, or attempt or provide a means to execute any “bulk download” operations;
2. modify the Groupon Content, or use it to update or create your own database of business listing information;
3. create or disclose metrics about, or perform any statistical analysis of, the API or Groupon Content;
4. use the API on behalf of any third party;”

So what does this mean for a developer using the Groupon API?

1.  Their application can’t do any caching which could include Groupon data.  Caching is an important performance tool for every application I have ever developed.  Having to fetch Groupon data on every page load could cause serious performance problems. 

2.  You may not store any Groupon content in a database of “business listing information”.  Humm can’t store data I get from your API in a database, can’t cache it.  Now what can I do with it?

3.  You may not do any statistical analysis of the API or content retrieved therefrom.  So I can’t say create an application which aggregates daily sales from Groupon across my state and shows trends?  I can’t use New Relic to measure the response time of the API calls to Groupon’s servers.  I can’t even use Google analytics to track the API calls.  Back to the data, my application can’t do any statistical analysis of “Groupon Content” at all.  Like say showing sales trends, pricing trends, category trends, geotag bucketing, category analysis, pretty much any kind of analysis which might add value to the “content” delivered through the API.  So why is my application retrieving this data again?

4.  A software developer may not use the API for their client. That would be “using the API on behalf of a third party.” 

Well you say, there may be legitimate technical reasons for all the above legal gobblygook like Groupon wants you to always have the most up to date information and doesn’t want competitors scraping their site, and yes I can make a long list of excuses too.  But wait, there’s more.  Yes because Groupon is fundamentally all about building a consumer brand and protecting it, there is an additional little missive from their lawyers happily entitled “Groupon Branding Requirements”.  I will have to admit this is the first time I have seen this level of hubris from any company.  Just a few choice snippets. 

“If you’re only going to recreate the functionality of Groupon’s own web site or mobile apps, save yourself the trouble and just put up a link.”  Ah, now that’s how you motivate a developer community!

“Don’t aggregate our deals with other providers.”  Humm but my application is actually trying to provide consumer value.  A major way of doing that is compare/contrast and help navigate the various daily deal site data.  Oh, but Groupon doesn’t want that level of scrutiny of their deals. 

“Wherever you display our content, you must prominently display our logo.”  I don’t have problem with credit, but the logo’s come with minimum sizes that are quite large and have specific color schemes that may not work with my application. 

After reading all the documents and requirements around the Groupon API it is clear that they have take the “my data and brand is more important than your application” approach to their API.   That is fine.  Good luck with that.