When working with a Box Enterprise that has tens of thousands of users, scripts designed to do things like user information syncing, group syncing, or user provisioning/deprovisioning often run into real issues with the Box API rate limits.

Some calls (e.g. downloading or uploading a file) are clearly significantly more resource-intensive than others (e.g. getting a user’s aliases). The method Google has implemented for the Gmail API (see https://developers.google.com/gmail/api/v1/reference/quota) seems like a really great way to balance the need to protect the back-end systems against the need for increased performance for less-intensive calls. It would be nice if Box implemented a similar model.

With webhook V1, we have the upper bound of 100 users in "touserids" field for each notification, so when a webhook has too many recipients (that is, more than 100 users are to be set in "touserids" field), we send multiple webhook notification for a single event so "touserids" is kept within 100 users for each notification.

For e.g. if an upload event was to trigger notification to 1000 recipients, we send 10 webhook notifications to the notification url with 100 users embedded in "touserids" field of each notification.

This causes duplicate notifications be sent to notification url although we only want to receive a single notification for a single event. We want this 100 users limit expanded so we can avoid this.

It would be great if we have a bulk API option. I would like to pass in the list of entity ids(could be files, folders users etc) and get back the results. This will reduce the number of api calls we do to get all the information.

We try to manage client's storage accounts and the main problem is with rate limiting for a large clients.

Implementation can vary, either limit the response size or provide an ack id and developers can poll for the id and get the data back once the api is ready to spit out the data in form of CSV. This would greatly help us reduce the api calls

It is currently disallowed to use redirect_urls of the form http://127.0.0.1 in published apps.

These give the error "insecureredirecturi".

These are allowed in unpublished apps.

Having a redirect to 127.0.0.1 is very useful for native apps which run on the users computer (eg rclone https://rclone.org ).

It is pretty much impossible to do https to 127.0.0.1 - you can't get a valid certificate for it. See this link for details: https://letsencrypt.org/docs/certificates-for-localhost/ - and also for reasons why using http://127.0.0.1 is treated as secure by browsers.

I'll describe how rclone, a native CLI app works. Rclone runs on the users computer - it runs a local webserver to get the auth details so the communications done over http are from the users browser to the users computer and never reach the LAN or Internet. Modern browsers treat http://127.0.0.1 as secure as the traffic never runs over the Internet or even the local network.

This is more secure than having to use an external https server which then redirects to http://127.0.0.1 as the credentials go straight to the CLI application and don't have to go over the Internet at all or travel through another server.

Note that almost all the other oauth providers that rclone supports allow http://127.0.0.1 redirect_urls, this includes Google Drive, Amazon Cloud Drive, Dropbox, Google Cloud Storage, Google Photos, Hubic, MailRu, pcloud, sharefile, Yandex (and more!)

So box is looking like the odd one out here!

Please implement this feature - thank you :-)

Request:
It would be really helpful if the service account login were displayed on the JWT app configuration page. This would make it easy to identify the login without having to run a separate script and would lower the barrier to entry for developing unprivileged BOX JWT apps.

Background:
We are making heavy use of service accounts to promote development server/automation-friendly Box apps. Our development model, outlined here (https://github.com/box-community/sample-jwt-app-primer) involves inviting low-privilege service accounts to collaborate on folders. This enables programatic access to Box files on a selective basis.

A major pain point is identifying the login associated with the service account. It currently requires the app developer to run a script that authenticates as the service account, fetches the service account metadata, and prints login to the screen. (Examples of that script are included in the linked repo above.) This is a frequent point of confusion and frustration for our developers, many of whom are working with the Box API for the first time.

It would be great to see full macOS support in the Box SDK.

I realize that the name of the Apple-flavored SDK is "box-ios-sdk", but "osx" is listed as one of the supported platforms. It compiles and links just fine, but the code path bails on OAuth sign in support.

It looks like most of the SDK would work fine for API calls post authentication, so I think it's mainly a matter of wiring up browser-based sign-in like Dropbox does for their SDK: https://github.com/dropbox/SwiftyDropbox. This seems to be confirmed by a response from @sujaygarlanka in a submitted GitHub issue: https://github.com/box/box-ios-sdk/issues/702 where it's suggested that I could use developer token auth. With that approach, I can only access my account, making it so that I could never build a Mac app for other Box users (making the SDK not particularly useful for most use cases on Mac).

Thanks for your consideration!