Skip to main content
Solved

Regarding Limitations When Using Box with Salesforce

  • March 4, 2026
  • 1 reply
  • 94 views

We have installed and are currently using Box for Salesforce in our Salesforce environment.

We are now considering adding new functionality in Salesforce to integrate more closely with Box. Specifically, we are planning to develop a feature that automatically grants permissions to the corresponding folder in Box when a user is granted record-level access in Salesforce.

Under the standard specifications of Box for Salesforce, permissions on the Box side are granted when the relevant user accesses the corresponding record in Salesforce. However, we would like to enable users to search and access content in Box without requiring them to first access the related record in Salesforce.

To achieve this, we are considering using the box.Toolkit included in Box for Salesforce.

Before proceeding, we would like to confirm the following technical constraints and specifications regarding the use of box.Toolkit:

  • Is it correct to understand that API calls made via box.Toolkit are not counted toward the Box API call limit?

  • Is it correct to understand that Box rate limits (e.g., HTTP 429 responses, such as 1000 requests per minute per user) still apply when using box.Toolkit?

  • Does box.Toolkit automatically retry when it receives a 429 response?

  • If retries are performed, does it wait for the number of seconds specified in the "Retry-After" header before retrying? Also, what are the maximum number of retry attempts and the maximum wait time?

  • If retries are exhausted, does commitChanges() throw an exception? How is the result ultimately returned?

  • When running scheduled batch jobs, which Box account acts as the executing entity for Box API calls made through box.Toolkit?

  • If multiple Salesforce users are subject to permission synchronization, is the API execution entity (Box account) fixed to a single account, or is it distributed depending on the target users?
    For example, if there are 50 target users, are the APIs executed as the respective Box users associated with each of the 50 users (i.e., distributed across 50 accounts)?

  • Aside from API call limits and rate limits, are there any other constraints or limitations we should be aware of?

  • Are there any additional concerns or considerations we should keep in mind during development?

We would greatly appreciate your guidance on the above points.

Best answer by DavidAtBox

  • Is it correct to understand that API calls made via box.Toolkit are not counted toward the Box API call limit? Correct. Toolkit api calls are not charged. 

  • Is it correct to understand that Box rate limits (e.g., HTTP 429 responses, such as 1000 requests per minute per user) still apply when using box.Toolkit? Yes. Rate limits still apply. 

  • Does box.Toolkit automatically retry when it receives a 429 response? It does not. In general we don’t find many people encountering rate limits. 

  • If retries are performed, does it wait for the number of seconds specified in the "Retry-After" header before retrying? Also, what are the maximum number of retry attempts and the maximum wait time?

  • If retries are exhausted, does commitChanges() throw an exception? How is the result ultimately returned? This is one of the reasons we don’t retry. It would be very easy to reach limits. 

  • When running scheduled batch jobs, which Box account acts as the executing entity for Box API calls made through box.Toolkit? It generally depends on the method call. Most calls end up being the service account as it has access to provide collabs.

  • If multiple Salesforce users are subject to permission synchronization, is the API execution entity (Box account) fixed to a single account, or is it distributed depending on the target users?
    For example, if there are 50 target users, are the APIs executed as the respective Box users associated with each of the 50 users (i.e., distributed across 50 accounts)? I am not sure if I understand this, but the collaboration is done as the service account as that account owns the folder to share.

  • Aside from API call limits and rate limits, are there any other constraints or limitations we should be aware of? Generally the issue is that User access in SF does provide some sort of event bus to listen to, so real time synchronization isn’t realistic, the best you can do is some sort of periodic sync. 

  • Are there any additional concerns or considerations we should keep in mind during development? Mostly just keep scalability concerns in both platforms. 

1 reply

  • Box Employee
  • Answer
  • March 5, 2026
  • Is it correct to understand that API calls made via box.Toolkit are not counted toward the Box API call limit? Correct. Toolkit api calls are not charged. 

  • Is it correct to understand that Box rate limits (e.g., HTTP 429 responses, such as 1000 requests per minute per user) still apply when using box.Toolkit? Yes. Rate limits still apply. 

  • Does box.Toolkit automatically retry when it receives a 429 response? It does not. In general we don’t find many people encountering rate limits. 

  • If retries are performed, does it wait for the number of seconds specified in the "Retry-After" header before retrying? Also, what are the maximum number of retry attempts and the maximum wait time?

  • If retries are exhausted, does commitChanges() throw an exception? How is the result ultimately returned? This is one of the reasons we don’t retry. It would be very easy to reach limits. 

  • When running scheduled batch jobs, which Box account acts as the executing entity for Box API calls made through box.Toolkit? It generally depends on the method call. Most calls end up being the service account as it has access to provide collabs.

  • If multiple Salesforce users are subject to permission synchronization, is the API execution entity (Box account) fixed to a single account, or is it distributed depending on the target users?
    For example, if there are 50 target users, are the APIs executed as the respective Box users associated with each of the 50 users (i.e., distributed across 50 accounts)? I am not sure if I understand this, but the collaboration is done as the service account as that account owns the folder to share.

  • Aside from API call limits and rate limits, are there any other constraints or limitations we should be aware of? Generally the issue is that User access in SF does provide some sort of event bus to listen to, so real time synchronization isn’t realistic, the best you can do is some sort of periodic sync. 

  • Are there any additional concerns or considerations we should keep in mind during development? Mostly just keep scalability concerns in both platforms.