Category Archives: Content

Merchant Verified Places

Sample “Verified” Icon

How do you know the information on local businesses provided is accurate?  We just added one more way for you and your users to know the info we’re providing is top-notch.  In our Places Detail API response, we provide a “claimed” element that lets you know if the merchant has verified their listing.

Beyond these places being flagged as “claimed”, they often also contain additional content. Local business owners can add images, a teaser, an offer, and external menu or reservation urls.  They can also customize how their name and address are displayed across the CityGrid network.  Merchants can claim their listings today on, and in the future possibly from your own site or application.  The process involves phone-verification in order to minimize fraudulent claims.

Start using the “claimed” element today to show your users know the information they see is verified.

Tags for all!

You asked for it and now you got it – an easy way to reference our taxonomy of tags.  I hope this will inspire you to do more and create more innovate apps on top of CityGrid APIs.  Using the taxonomy you can create dynamic applications, browse and breadcrumb functionalities and other rich ways to interact with local data and find more relevant Places for your users.

Our taxonomy is published daily in two formats: first as a list (available here) and second as a tree (available here).  Both are in json format.

Want more details? Check out our documentation on tags.

Better Round Trip-times (RTT) With CityGrid API Using GZip

One of the biggest questions I get when talking with CityGrid developers are around storing our data. Everyone wants to store the 15 million businesses CityGrid has in their own database. My response is really? You do?

This type of thinking comes from legacy thoughts around database driven applications and concerns about network latency. I counter these with a couple of points:

  1. You don’t want to be in big data business, we have teams of engineers working to ingest, clean, optimize and serve up this data. Do you really want to assume these responsibility.
  2. Our places, images, reviews, offers and other content is updated in real-time. If you store the data, you’re missing out on a lot of content that may change frequently.
  3. Speed is getting to be less of a concern when making calls to our APIs–you are looking at millisecond responses and in some worst case scenarios, 1 or 2 seconds.

Usually I can convince most developers about points 1 and 2. But speed is still an ongoing battle. We are working all the time at CityGrid to improve our API response times. But there are things you the developer can do to improve response times also.

One tactic that isn’t available in our documentation, is the use of GZip. With each API request you can set a HTTP header as Accept-Encoding: gzip, and the CityGrid will compress the responses for you, significantly reducing your round-trip time (RTT). Once you receive the response from CityGrid API you can uncompress using the GZIP decoding functionality available in any programming language.

Reducing the size of the data being transmitted is a great way to increase your RTT, which makes relying on any API for real-time calls, much more realistic. I recommend giving it a try when integrating your web or mobile app with the CityGrid Places, Reviews and Offers APIs.