The DBX Platform helps bridge the silos between people and content by connecting the tools they use at work. We are excited to share the story of four developers who integrated with Dropbox to streamline workflows for their users.
This year we hosted Dropbox Developer Meetups in San Francisco, Seattle, and New York to connect with and inspire our local communities of developers. At each of these events, we conducted a panel discussion with developers to learn about their integrations with Dropbox, the use cases they solve, and their experience building with the Dropbox APIs. At our New York City event,
Edit 06/23/2017: Deprecation timeline updated to match the one described in our recent blog post.
As of today, Dropbox API v1 is deprecated. This includes both the user endpoints (a.k.a. the Core API), and the team endpoints (a.k.a. the Business API). In order to provide our developers with the most up-to-date features and support a single, consistent platform, we’ll be turning off API v1 a year from now, on 6/28/2017.
API v2 is built thoughtfully with a consistent design and adds new endpoints and features. Additionally, we’ve open-sourced our SDK generator,
[UPDATE March 24, 2016] The official date of retirement for the Datastore API is April 29th, 2016.
Last week, we announced a preview of the new Dropbox API v2, aimed at simplifying the experience of developing with Dropbox. As part of this effort to simplify our platform, we’ve decided to deprecate the Sync and Datastore APIs over the next 12 months.
If you’re one of the majority of developers using the Core API, your app will be unaffected. For those using the Sync or Datastore API,
[EDIT June 3, 2015] This post has been updated to reflect the latest API v2 syntax.
We’ve been working on a new version of the Dropbox API for a while and it’s time to show you what we have so far. To start, we’ve implemented a select set of endpoints that highlight the big structural changes underway, and we’d like to know what you think!
Overall, we’ve simplified our use of HTTP. For example, most endpoints always use HTTP POST, including those that return structured data. Requests take JSON in the body and responses return JSON in the body.
HTTP-based APIs often encode arguments as URL path and query parameters. For example, a call to the Dropbox API’s filename search endpoint might look like:
While URL encoding seems fine for simple examples, using JSON might have some advantages.
URL paths are complicated
In the example above, the first “+” is a literal plus sign because it’s in the URL. The second “+” represents a space because it’s in the URL query component. It’s easy to confuse the two since the encoding rules are mostly the same and sometimes the library functions are name something ambiguous like “urlencode”.