How to Download files in bulk with collaboration and file info by single rest api call?

New post



  • jcleblanc

    Hi Vivek,

    Unfortunately not all in one API call. Here's the sequence of how I might set this up if I needed that information:

    1. Get the list of all items in a folder using the list file items endpoint. 

    Then, for each item in the return from #1:

    1. Call the download file endpoint to get the file content (contains what you need for #3).
    2. Call the get file information endpoint to get file information (contains what you need in #1 and #2). I believe you'll need to also set "version_number" in the "fields" parameter of this call to return the version information, as it's not immediately available in the standard return object for this call (in the CLI this would look like box files:get 1234567890 --fields=version_number). 
    3. Call the file collaborations endpoint to get the collaborators on the file.

    - Jon

    Comment actions Permalink
  • Vivek Jain

    Hi Jon

    Thanks for you prompt response.

    There is one more quick question,

    If we make number of calls to get collaboration, file-info and file-download for multiple files, It would have any performance implications?


    Comment actions Permalink
  • jcleblanc

    The only issues that you should run into for app performance would be related to rate limits. I'm not sure what your integration looks like, but let me see if I can provide some general guidance here.

    Rate limits

    If you take a look at the rate limits page I provided above you can see that the limits are basically placed into two buckets, per user rate limits and per enterprise limits. If you have a lot of load to these API calls at once, from a single user, I would recommend looking into having some rudimentary queuing system in place. This system should be aware of the rate limits and be able to queue requests to make them over time if you have rate limit concerns. Any calls to the APIs should also listen for 429 rate limit errors. This should allow you to handle any rate limiting concerns without losing requests in transit.

    Service account calls

    One of the main issues that folks run into as they scale is that they make all API requests from the service account of a JWT application. While this might work in prototyping / minimal load conditions you will optimally want to instead make requests on behalf of the users (with a user access token or using an As-User header). Since the rate limits you'll most likely hit with this setup are per-user based, this would allow you to minimize load on any single account. Using a queuing system that I described above would allow you to handle the case where a single user does indeed need to make a lot of calls at once. If you don't have "users" in a traditional sense in the app, then you can use app users to function as worker accounts to spread load over multiple user types instead. 

    Hope that helps!


    Comment actions Permalink

Please sign in to leave a comment.