API v1 Shutdown Details

As previously announced, API v1 is being retired on Thursday, September 28th, 2017.

On this date, API v1 endpoints will return a 400 error with this message: {“error”: “v1_retired”}. This means any integrations or applications still relying on API v1 endpoints may stop working.

If you still have not migrated to v2, check out the migration guide for more details.

We built API v2 to create a more consistent, simplified, and scalable platform for developers, and we appreciate your patience and flexibility as we make this transition.

Read more

API v1 is now deprecated

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,

Read more

Deprecating the Sync and Datastore APIs

[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,

Read more

A preview of the new Dropbox API v2

[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!

What’s different?

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.

Read more

JSON in URLs

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”.

Read more