Today we released the Dribbble API v2. This marks a pretty big shift for us as we’ve removed quite a few endpoints from v1.
We’ve seen many clever and inspiring uses of our API. In fact, we acquired the Balllin’ app and hired developer Devin Ross who has evolved it into the official Dribbble iOS app.
But maintaining an API is expensive–it’s easy to return JSON from an HTTP request, but it’s another thing altogether to provide support, have an ongoing strategy as to what data can be exposed, and to predict how your data will be used and affect your business. And, perhaps most taxingly, to police abuse.
We’ve refocused v2 on providing a Publishing API. API v2 expands developers’ options for building applications and integrations that allow designers to publish their work on Dribbble, but removes the endpoints that offer aggregated streams of shots. We will continue to provide an endpoint to designers to list their own shots. Developers should plan to migrate their applications away from endpoints scheduled for removal. Developers should plan to migrate their applications away from the v1 endpoints scheduled for removal.
This was not an easy decision to make as we know many developers have used the Dribbble API to create experiences that provide design inspiration in a multitude of desktop, browser, and mobile apps.
As we continue to build out Dribbble API v2, we may consider extending additional endpoints to trusted, legitimate Dribbble apps on a case-by-case basis. Help us understand how your app impacts the Dribbble community by filling out our short v2 API survey.
When creating or updating a shot, can now optionally specify whether the shot is Low Profile by specifying
true for the shot’s
Shots now include
animated attribute. This will indicate whether or
not the highest resolution image is animated. Smaller image sizes are
still frames of the original animation.
User and team resources now include a
can_upload_shot attribute that indicates
if they can currently upload shot or not. While we currently limit users to 48
shots per month and five per day you can check this attribute without the
need to know the limits.
User and team resources now include
The team members endpoint allows you to retrieve the
members on a team. As a result
members_url attributes are
present on a team resource.
User and team resources now include
attributes. And user resources include a
The team shots endpoint allows you to retrieve all the shots
by the team and team members. As a result a
team_shots_url attribute is present on a team resource.
Attachments now include a
content_type attribute, so
there’s no need to parse the extension of the
url or perform a HEAD request to
determine it. If you’re showing attachment previews it should be much easier to
do so now.
Access to and manipulation of buckets, an often requested feature, are now available. You can retrieve and manipulate individual buckets and shots in buckets. As well as retrieve buckets for a shot or for a user.
The followers and following endpoints no longer simply return a user. It now
created_at attributes with the user nested in it. Depending
on the endpoint the user will be under the
See the followers documentation for updated examples.
Username mentions are now supported in comments. Nothing has changed with the
comment creation endpoint though. Any
@username in a comment will now automatically be parsed and linked, if
the username is valid of course.
We’ve added new endpoints for attachments. Listing attachments or retrieving a
single attachment are available for any scope. Creating or deleting attachments
Creating an attachment is also our first asynchronous endpoint, due to the processing required. Creating shots will behave similarly when added.
Read the full documentation to get started.