Application integration architecture questions

[brianmayer-neo]

Context

We are currently designing a middleware app that will be keeping the file system of another application in sync with a Dropbox because the organizations want to leverage Dropbox features and storage on top of what the other app is offering. We have a single customer in mind at the moment, but will be offering our product to other organizations using this particular app as well.

We are monitoring application events and running scheduled processes for all of your typical file system events. Nothing crazy. Except that since it is an application -level sync for an organization, the amount of data being moved is not insignificant.

Questions (numbered only for response reference)

1. I assume that each organization using this sync will need to create a service account created that will act as the user for our middleware app. Correct assumption?
2. I've read about the Data Transport Limits that apply to business accounts of various levels.  Our customers would always fall into that group. We have an internal system that can manage against external api limits; however, since this limit is not just for our own calls, what are best practices for mitigating availability? Are there different limits by plan type or some other mechanism? We expect our users each to be handling about 500k-1M uploads per month (not including other calls not relevant to the data transport limit). Any other considerations?
3. Your developer docs indicate that the app is not eligible for production review until it has 50 users. No problem. In our case we will have one "user" per customer syncing their entire other app to Dropbox. I just want to confirm that this doesn't change that.
4. Any other questions we should be asking?

[Greg-DB]

1. You can have an app use the Dropbox API to connect to any particular Dropbox account, including a Dropbox account created specifically for that purpose, in order to access anything in that connected account (as long as the app is registered for the Full Dropbox access type).
   
   However, you can alternatively have the app connect to the team itself (and not just a specific account). When using any "team scopes", the app gets connected to the entire team (and note that this kind of authorization can only be performed by a team admin). That way, it can access and operate on the entire team based on that one authorization. Refer to the OAuth Guide for more information.

2. The Dropbox API does have a general rate limiting system that applies to all account types, but we don't have specific rate numbers documented for that. Apps should be written to handle these rate limit responses automatically. Also note that not all responses with a 429 or 503 status code indicate explicit rate limiting, but in any case that you get a response with 429 or 503 status code the best practice is to retry the request, respecting the Retry-After header if given in the response, or using an exponential back-off, if not. I recommend referring to the error documentation and Error Handling Guide for more information.

   Additionally, there is a specific limit for uploads to some Dropbox team plans of "1 billion API calls/month" for "data transport" noted here, as you mentioned. This is a limit on the number of upload API calls that can be made per team per month, for certain Dropbox team plans only. Note that this only applies to upload calls, and not other types of calls. You can find more information on this limit in the developer documentation here.

3. This depends on whether the app is user-linked or team-linked (per item 1 above). For user-linked apps, if there will not be more than 50 different Dropbox accounts linked, you do not need apply for production. For team-linked apps, if there will not be more than 5 different Dropbox teams linked, you do not need to apply for production. You can find more information on that here.
   
   
4. Since you'll be interacting with files and folders via the API, I recommend reading the File Access Guide and Team Files Guide. This post and code sample may also be helpful.