License Restrictions for API Users

API users are client applications that sign in to MYOB Acumatica by using one of the following ways:

• The sign-in method of the contract-based REST API
• The sign-in method of the screen-based SOAP API
• The OAuth 2.0 mechanism of authorization for applications

Each MYOB Acumatica license includes the limits on the number of web services API users, the number of concurrent API requests, and the number of web services API requests per minute. You can view these limits of the MYOB Acumatica license on the License Monitoring Console (SM604000) form. The trial license sets the limit on the number of web services API users to two and imposes no other limits.

The following sections describe these limits and the lifecycle of API requests.

Number of Web Services API Users

On the License tab of the License Monitoring Console (SM604000) form, the Maximum Number of Web Services API Users box displays the license restriction for the number of API users that can work with MYOB Acumatica. When an extra API user tries to sign in to the system and the number of API user sessions exceeds your license restriction, an error message is returned and the sign-in process is interrupted. The following diagram shows an example of how this limitation works with three sign-in requests when the Maximum Number of Web Services API Users is set to 2.

To avoid exceeding the maximum number of API users, external applications must properly implement the signing in to and signing out from MYOB Acumatica. If an external application does not close its sessions in MYOB Acumatica (that is, does not sign out from MYOB Acumatica in each session), this application can prevent other applications from signing in. For details about the implementation of signing in and signing out, see the following sources:

• Sign In to the Service for the REST API
• Login() Method for the screen-based SOAP API

Number of Concurrent Web Services API Requests

All incoming API requests (except the requests to sign out from MYOB Acumatica, which are processed immediately) are placed in an internal queue. To process these requests, the server uses the API processing cores, which execute the requests in parallel. The number of cores is no more than the maximum number of concurrent web services API requests, which is specified in the Maximum Number of Concurrent Web Services API Requests box on the License tab of the License Monitoring Console (SM604000) form.

The API processing cores take the requests from the queue one by one. If the limit for the number of concurrent web services API requests has been reached (that is, if all API cores are processing the requests), the next concurrent request waits in the queue and is processed when one of the previous requests has completed. These requests in the queue are taken into account in the statistics of the delayed requests (see Lifecycle of the Requests).

The following diagram shows an example of how this limitation works with Maximum Number of Concurrent Web Services API Requests set to 3.

Number of Web Services API Requests per Minute

The maximum number of requests that can be processed per minute is specified in the Maximum Number of Web Services API Requests per Minute box on the License tab of the License Monitoring Console (SM604000) form. If the number of requests in a particular minute reaches 50% of the limit specified for the license, the subsequent requests during this minute are delayed for the following time: 60 seconds minus the number of seconds that have passed since the beginning of the current minute, divided by the remaining number of requests that can be processed in the minute (per the specified maximum). These delayed requests are taken into account in the statistics (see Lifecycle of the Requests).

For example, suppose that in a particular license, the limit of the number of web services API requests per minute is 50. Since the beginning of the current minute, if the system has already processed 25 requests in 40 seconds and the system receives another request, this request is delayed in the internal queue for 10 seconds, calculated as (60 - 40) / (50 - 25). After this delay, the request will be processed.

The following diagram shows an example of how this limitation works with Maximum Number of Web Services API Requests per Minute set to 50 and with 25 requests processed in the minute.

Decline of the Requests

The request will be declined only if the number of requests in the internal queue is greater than 20, or the request remains in the queue for more than 10 minutes. MYOB Acumatica gives no indication that a request is added to the queue or being processed; the application that makes a request should stay connected and wait for the response.

For example, suppose that during one second, each of 50 external applications sends a web services API request to one MYOB Acumatica server. Suppose also that each request is processed for 1 second and that the maximum number of concurrent web services API requests in the license is 16. In this case, the first 16 requests will be passed to 16 API processing cores immediately. The next 20 requests will wait in the internal queue, and the last 14 requests will be declined.

Lifecycle of the Requests

The system sends a response to the request when the request is fully processed or declined. You can view the statistics of the delayed and declined requests on the Statistics tab of the License Monitoring Console (SM604000) form.

The following diagram shows the lifecycle of a web services API request. For details about how the sign-in requests are processed, see Limitation of API Connections for Integrated Applications.