My personal favorite apps that use the API:

plaintext: http://itunes.apple.com/us/app/plaintext-dropbox-text-editin...

http://ifttt.com

https://www.hellofax.com

http://greplin.com

Two apps I use almost daily that use the API:

- https://agilebits.com/onepassword/android

- http://www.quickoffice.com/quickoffice_pro_android/

As a former Quickoffice employee, I love seeing people actually using the app.

hellofax uses dropbox api? That's sweet - but I can't figure out exactly how they use it?

Juxta - we just did a redesign last week and haven't updated all the "how to" posts.

Here's a screenshot of how to integrate HelloFax with Dropbox https://img.skitch.com/20111021-b2qqr3rbh5uew4jxh4c4n83pe7.j...

Hope that helps!

My sister (Eva) needed to use Hellofax a few days ago after I asked her to sign something digitally. She didn't know how, but when she got your automated "Let me know if you need any help" email, she wrote back with some questions. You (assuming you're Joseph) helped her figure out how to use it, and then she called me and was absolutely GLOWING about how cool it was to email back and forth with you, get help, and have a fun conversation. She also loved the "Stay Faxy" line you used somewhere.

Just wanted to say thanks, awesome job, and I think you converted her into a Hellofax customer for life.

Wow, so could that plain text file be a JavaScript file in my public Dropbox folder?

yep. You'll want to change it so Plaintext doesn't operate out of a folder, but can see your whole Dropbox. See FAQ #11 here: http://www.hogbaysoftware.com/products/plaintext/faq

I've been working with the Dropbox API (among MANY others...) for my early stage startup Snapier (http://snapier.com/), and I must say it is a pleasure to work with. Very sensible and logical. I can't say that about all API's...

Another example of how Dropbox is gonna keep its momentum. With it, it should be rather straightforward to bake in some cool iCloud type of preview/revision stuff into native apps.

In Snapier, it will be better if you have a message why you are asking for emails. More importantly, provide a message which is a little more than "Thank you very much" when I enter my email. Though I got an email within a second, it will be more user friendly to give a "We'll connect back soon" in the site itself.

Also, in the email you mention 'check us out on Twitter' but fail to provide the twitter id.

Just my two cents. If any of that sounds badly phrased, I blame the clock for showing 3 AM. Cheers :)

Thanks for the feedback. It was very slapdash but we hope to replace it with something more... robust soon.

Also, it would be nice to have a better description of what Snapier does exactly. 'A simple way to automatically sync data between Skype and Facebook'? What kind of data would I want to sync between those two services? I read your blog and if I understand correctly, Snapier would be something that get's my credentials for a bunch of API's and then interconnects them, so that I don't have to roll out a script to do it. If my understanding is correct, then this is not very well reflected in your landing page.

You do understand correctly, and we think this is a big challenge for us. We are trying to stay away from "technical" terms (save for the API nod in the name) but stay light on the marketing speak. I could go on and on about our plans here... but, to cut it short, you are absolutely right, it isn't reflected correctly on the landing page.

So, Snapier is like IF THIS THEN THAT but without the IF?

http://ifttt.com

Very similar, ifttt.com is definitely an inspiration (as is Yahoo! Pipes). However, we have a very different and more promising direction (we think!).

This is excellent: I especially like revision control and "undelete" (still not as powerful as Google Docs but enough for majority of apps).

Allowing access to only a single folder is an excellent feature (Google Docs does not have that): basically you can make Dropbox as a dropbox or sendbox.

And shameless plug: if you need to real-time replication of multiple Basecamp/Google Doc accounts with Dropbox try this: https://cloudHQ.net/ (and you probably understand why we are excited to finally get "single folder access feature").

Finally, Dropbox lets apps request access to only a single folder. Now you can try out an app without worrying that you're giving access to your private data.

Many people were asking about this feature on Hacker News just yesterday: https://news.ycombinator.com/item?id=3136098

Unfortunately there is no way to share app sandbox folders limiting their use in multiuser environments: https://www.dropbox.com/votebox/1916/share-app-sandbox-folde...

Maybe I'm missing something, but doesn't the way the app authentication works preclude it from being used for client-side apps?

For example in https://www.dropbox.com/developers/start/authentication#pyth... you set both APP_KEY and APP_SECRET. Of course anyone can read the source and get these, so what keeps them from impersonating your app by using the same key and secret?

For iOS and Android this is probably less of an issue, but someone could probably glean the values by searching your binary.

Before the redesign they had a page that explained the API is not for desktop client use, only mobile and web apps. I can't find the new equivalent, but maybe I'm missing something.

For mobile you can embed the key and secret, because they only work in combination with someone authenticating their account to use your app https://www.dropbox.com/developers/start/authentication#ios

I understand that, but what keeps someone from pulling your key and secret out of your app and creating a trojan app? For example the app could look like your app, use the same key and secret, still authenticate as the user, but then steal their data and upload it to a third party server.

That may not be easily doable with iOS since Apple does a good job of curating their market, but I can imagine someone making a fake app like this that runs on Android and getting in to the Android market.

That is a risk, Twitter has the same risk, and when they switched over to OAuth-only there was a debate about this. Twitter's stance was that it's the developer's responsibility to obfuscate your app secret. People promptly pulled apart the official twitter iPad app and found they had done a terrible job of obfuscating it themselves...

In my opinion the big difference here is that a compromised Dropbox key would give the malicious app access to data it wouldn't normally be able to access. A stolen Twitter API key just lets the app act as any other Twitter app does, there's not really any additional data it would be privy to.

I haven't had a chance to look into exactly how authentication works, but if going to the page would require that the user regrant access each time (and if the page would indicate the app name as well), this difference could be nullified.

That's a weird reasoning of them. If the app-secret is ever sent over the network directly (either HTTP or HTTPS) there are plenty of ways to intercept it without having to dig into executables. I quickly skimmed over the OAuth code and that seems to be the case. But maybe they support digest-based authentication as well.

If you can now run automated searches across multiple Dropbox accounts, think what that does for aggregating file storage and sharing.

Imagine how easy it would be to build a multi-user pseudo-P2P file search/share app on top of Dropbox now.

Or imagine when a user can sync/export their settings from a "cloud" service to a SQLite file in their Dropbox automatically.

Kudos to the Dropbox team for developing their product into a platform. Giving developers an opportunity to develop things on top of their product keeps not only the community excited about things to do with Dropbox, it also gives them fresh ideas from how people consider to use it.

Aw man, awesome stuff. Searching, revisions... those things are really helpful.

I'm still hoping that POST notifications / webhooks will be introduced soon. That will definitely make the web a better place.

This is interesting although I really really wished they had used oauth v2 since it is so much better and is designed to give a first class experience on mobile devices.

In fact I can't think of any good reason to use the older version but I would like to hear if there are anybody who has different experiences since I haven't worked much with it.

If you use the SDKs on mobile devices, users can auth via their Dropbox native app if they have it installed. https://www.dropbox.com/developers/reference/sdk

OAuth 2 is way simpler but requires HTTPS, which may have overhead at scale.

Everything has overhead at scale. I think the 'HTTPS is hard on computers' stage has passed by though...its just not that computationally intensive on modern hardware.

Obligatory reference: "SSL/TLS is not computationally expensive any more."

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

Seems like its all server code. It'd be nice to do x-domain posts straight from the browser to Dropbox.

Though it's still a young project, you might be interested in Unhosted: http://unhosted.org/

It's an OSS project that kind of aims at doing that kind of stuff. (if I'm not mistaking your post)

If it is not possible, I think it is more a web programming limitation rather than Dropbox failing to implement something.

Everything their SDKs do can also be done using their REST API (https://www.dropbox.com/developers/reference/api) and they support JSONP to allow cross-domain GET queries. However, my understanding is that JSONP is not supported for other REST methods, most importantly POSTs. A person claims to have found a workaround for doing POSTs via JSONP here: http://stackoverflow.com/questions/5345493/using-put-post-de....

Has anyone tried that or know of a way to do cross-domain POSTs?

You can do cross-domain POSTs. You just cannot get a response from the server. Often times though you can get the length of the response. This can be used to do a POST to change settings on an unsecured Wi-Fi routers, for example and checking whether the call succeeded or not by the length of the response.

The method described in the SO answer is similar, from what I can tell, to what DISQUS uses. I believe they call it JSONPI: http://alexsexton.com/thirdparty/#forms-are-cool-too

This would be incredible. Web apps that are 100% HTML5/Javascript/LocalStorage could then use Dropbox to store/retrieve data in the cloud.

I'm hoping someone will tell me why it's a security problem, but yeah, for a whole slew of apps, I'd like eliminate server logic or at least make it simple to swap out backends.

How would that differ from S3? Is the concept that people would also have a better local UI on their data directory?

It is much cheaper to scale an application putting data onto peoples' Dropbox folders instead of S3. For S3, you would have to pay for the total amount of storage used by your customers; with Dropbox you wouldn't have to pay anything for storage, and for the most part your users wouldn't have to either since each gets a certain amount for free.

Exactly. With Dropbox, you're making storage the customer's problem and not yours. You could argue this is bad for the customer, but you end up with a web app with next-to-no server overhead: just serve your static files and everything else is taken care of. No different than the many mobile apps that sync to iCloud/Dropbox already.

Is there a way to discover which user uploaded a particular revision of a file (to a shared folder)?

Revisions! Somebody should hack together a "Dropbox Time Machine" this weekend!