Introducing bit.ly API Version 3
Jehiah Czebotar
At bit.ly we've been working hard to improve the speed and reliability
of our API endpoints, provide simpler, more consistent response
formats, and clarify our API documentation. This V3 release goes a
long way towards accomplishing those goals. All V3 methods support
identical JSON and XML response formats. JSONP is likewise universally
supported, and many methods support an additional plain text response
format.
We have also added a simpler, more efficient method to lookup bit.ly
click counts, as well as a method to query bitly.Pro domain status.
Many of these changes started as user requests, and we are looking
forward to adding more API endpoints to access bit.ly data based on
your feedback.
Previous versions of the API are being deprecated in favor of V3
endpoints. In a following post, we will detail the phaseout schedule.
For the time being, existing API endpoints will remain active, but we
encourage you to upgrade your client libraries and API calls to the
newest version at your earliest convenience. Additionally, upcoming
endpoints that provide increased functionality will only be rolled out
via the V3 interface.
--
Jehiah
Scott Herbert
--
You are subscribed to the bit.ly API discussion group.
To post, email to bitl...@googlegroups.com
For more options, visit http://groups.google.com/group/bitly-api
To unsubscribe from this group, send email to bitly-api+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
--
--
Scott Herbert
Web: http://www.our-party.org.uk/
Twitter: http://twitter.com/Scott_Herbert
Linkedin: http://www.linkedin.com/in/scottaherbert
Neil
The v3 documentation mentions that Bit.ly imposes per-hour, per-
minute, and per-IP rate limits for each API method, but does not
mention what those limits are. Could you please discuss these? Also,
do you plan on implementing a method so that we can check the rate
limit status?
The ability API calls is a *VERY* welcome addition. Thank you!
-- Neil
Scott Herbert
Nice,
Any idea when Version 2 will be deprecated? I'll update my app, but as it's a windows based client their may be older version that will end-up brakeing.
So it would be nice to give ppl a cut off date.
--
You are subscribed to the bit.ly API discussion group.
To post, email to bitl...@googlegroups.com
For more options, visit http://groups.google.com/group/bitly-api
To unsubscribe from this group, send email to bitly-api+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
Jehiah Czebotar
<scott.a...@googlemail.com> wrote:
> Any idea when Version 2 will be deprecated? I'll update my app, but
> as it's a windows based client their may be older version that will end-up
> brakeing.
>
> So it would be nice to give ppl a cut off date.
>
we completely understand that it takes time to roll out application
updates, so we are going to see how fast the uptake of the new v3
endpoints happens before deciding on and end-of-life for v2 endpoints.
It will however be on an order of months not weeks.
--
Jehiah
Jehiah Czebotar
> Jehiah,
>
> The v3 documentation mentions that Bit.ly imposes per-hour, per-
> minute, and per-IP rate limits for each API method, but does not
> mention what those limits are. Could you please discuss these? Also,
> do you plan on implementing a method so that we can check the rate
> limit status?
>
> The ability API calls is a *VERY* welcome addition. Thank you!
>
> -- Neil
>
yes and yes!
Our goal of rate limits is of course to make sure they are high enough
that you can do interesting things, but low enough to stop abuse that
degrades the service for everyone. We are not yet ready to expose the
default limits, but are looking forward to being able to do so in the
future.
I can also describe a little about how these work. The primary limits
that come into play are the hourly and per-minute limits on each
method. These limits are per-method, so that the limit on /v3/shorten
does not impact the limit on /v3/clicks, and they re-set at the end of
every hour. The per-minute limit is simply a burst limit at 1/10th the
hourly limit.
As always, make sure you check for rate limit responses from the api,
and if you run into any issues with the limits drop us a line at
sup...@bit.ly
--
Jehiah
Neil
Thanks for the extra info.
The batching support should alleviate some of the stress on the
servers, at least from API calls. Could you please make it clear in
the documentation that the batching support is limited to 15 lookup
parameters. For example, if you call the clicks method, you can pass
any number of hashes or short URLs as long as the combined number of
both types of parameter is <= 15.
-- Neil
Jehiah Czebotar
> The batching support should alleviate some of the stress on the
> servers, at least from API calls. Could you please make it clear in
> the documentation that the batching support is limited to 15 lookup
> parameters. For example, if you call the clicks method, you can pass
> any number of hashes or short URLs as long as the combined number of
> both types of parameter is <= 15.
>
good catch; i'll get the docs updated to reflect that limit.
--
Jehiah
Eiji Kitamura
Congrats on your new API release.
I've quickly read through documentation but couldn't find the "/info"
API which used to be in v2.
I want to get htmlTitle of the page along with the long url.
Is it deprecated? why? any plan to add htmlTitle to "/clicks" or "/
expand"?
(Personal request: I want to retrieve click numbers and htmlTitle at
the same time)
Anyway, "/clicks" API is cool!
Feras Al Natsheh
--
You are subscribed to the bit.ly API discussion group.
To post, email to bitl...@googlegroups.com
For more options, visit http://groups.google.com/group/bitly-api
To unsubscribe, reply using "remove me" as the subject.
Jehiah Czebotar
similar to the v2 /info call. This is intentional while we work to
restructure some of that content.
--
Jehiah
![Jay R. [dlvr.it]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
Jay R. [dlvr.it]
the benefits/differences between login and x_login. What's the
purpose? Why would you need or want to send both parameters?
Jehiah Czebotar
authenticate based on your credentials and still make operations on
behalf of the user.
This allows us to give you as a developer feedback on your full
request volume when performing operations on behalf of others, and
helps clarify situations that would otherwise look like abuse of user
credentials. It also helps direct us to the right location (the
application developer) when there are problems that need to be
resolved.
--
Jehiah
CDressler
that uses your APIs. One of our big asks was the ability to look up a
users history so we can show them tracking information. Currently, I
can only show them tracking history for URLs that they shorten on the
device, but anything else done outside of our app we can't see. I know
this was potentially in the works, any idea on when this might show
up?
I'm happy to help with developing use cases or whatever else you might
need to help light this feature up. We are working on our iPad app as
well as a richer history feature would be awesome!
Thanks!
Chris
Neil
You can already get the history, albeit limited to the last 15
shortened URLs. You just have to think outside of the API box. Think
RSS! Hint: that's how my iPhone app, Linkie, gets the job done.
I too would like to see an API endpoint that allows the retrieval of
the history, but with paging support. That would be similar to the way
the web UI currently works. While I'm at it, throw in the location and
timeline data (as seen on the info pages) into the API and I'll be
happy.
-- Neil
wduvall
but the examples use the uri parameter. Which is the preferred
parameter to use for v3?
longUrl is a long URL to be shortened (example: http://betaworks.com/).
http://api.bit.ly/v3/shorten?login=bitlyapidemo&apiKey=R_0da49e0a9118ff35f52f629d2d71bf07&uri=http%3A%2F%2Fbetaworks.com%2F&format=json
http://api.bit.ly/v3/shorten?login=bitlyapidemo&apiKey=R_0da49e0a9118ff35f52f629d2d71bf07&uri=http%3A%2F%2Fbetaworks.com%2F&format=xml
CDressler
Thanks for the reply! Yep I'd considered doing that before but was
worried it only gave the last 15 shortened URLs and was imagining all
the support e-mails "where are the rest??" kind of thing. Still
weighing that, but really hoping they finally give a history API! :)