github twitter linkedin email rss
My experience with Bitly API
Apr 5, 2011
4 minutes read

## Introduction

Bit.ly is an URL shortener service available on http://bit.ly/, it also provides a public API for existing (free or not) accounts.

API Documentation

There was the idea of using Bit.ly for our internal URL shortening service. I decided to use an existing ruby wrapper for their API and test what options were available.

Ruby Wrapper, also available on rubygems for ruby >= 1.8.7

This wrapper allows for most if not all the API version 3 endpoints and features needing only the username and API key which is available in the website for all existing users.

API Key

Example use of wrapper

After the setup I did a small number of tests that example the work of the wrapper with the API.

require ‘rubygems’

require 'bitly’

Bitly.use_api_version_3

bitly_client = Bitly.new('username’,'apikey’)

expand = bitly_client.expand('http://bit.ly/xxx’)

google_url = bitly_client.shorten('http://google.com’)

Ideas and results on the wrapper

This allows us to create new URLs, find the original URL and get stats like number of counts on the URL and number of global counts, which are all the shortened URLs that represent the same long URL from different users.

There is a very simple way to see the stats and some very nice charts for an existing bit.ly URL even if it’s not from our user by adding a plus sign in the end of the URL i.e. ‘http://bit.ly/xxx+’

One of the features that was not present in the API was being able to add new custom URLs and it seems that it will always shorten to the long URL to the unique private URL set in the account (this feature is only available for Pro accounts)

Another interesting feature that seems to be missing is the possibility of having two different shortened URLs for the same original long URL with the same user. This can be worked around by adding parameters to the URL which will not be used but that feels ‘hacky’ as it might influence the behaviour of the URL and will be seen by the user. Would be good to have different start points for the same URL and use the statistics with that.

In the documentation they refer that if you need to shorten a URL for another end user you need to use it’s username and api key, so we would need different Bit.ly Pro users to split these duplicated URLs!

## Why I’m not going to continue with this spike

I was thinking on building an internal web endpoint where people could easily add new URLs, check their own statistics and check the general statistics but this would mean building all the statistics analysis, somewhere to hold the existing users and URLs, caching for existing data (as seen in the Bit.ly API best practices document)

Which means everything would be built except the actual shortening! So the options actually are:

1 - Do everything in-house, build our own URL shortener and keep the data we need centralised, this would drop all the API calls you would need.

2 - Just use Bit.ly’s own dashboards and forms and give it to the consumer team, it will be up to date, tested and not another project to maintain. Also the Pro account allows us to track a specific domain on the live dashboard instead of hitting the stats page for all of those domain’s URLs.

## Could we do something useful with the API?

This would be useful if we want to automate the creation of shortened URLs and use Bit.ly’s dashboards internally - we could create a very simple plug-in to return the existing or new shortened URL if a user wants to share a page.

Having our own share links would help us focus the users to have the same shortening service so we keep the data in the same place instead of all the world’s services’ own dashboards.

But, there isn’t much to be done outside the Pro dashboard stats and domain tracking except for having our own shortened vanity URL automated (still good for brand value) and also there aren’t any future plans to add shortened share links to any of the web applications so the project would simply be locked away for months until it would be actually needed - by then all the API’s would have changed (if not even new/better competitors for the market).


Back to posts