Skip to main content

Using a an Azure Classic Cloud Service, we are making REST API calls to a 2020R2 instance (default endpoint), using a token granted through a Connected Application. So for each API request, we are including the “Bearer” header with the access token. This access token was acquired by a different system and sent to the cloud service to process an import/export of data. (The cloud service makes no “login” request, requests with username/password, no “logout” request, no token renewals)

When exporting data TO the Acumatica instance, depending on the amount of data to be executed, we make 25-1000+ API calls to that instance (checking if a record exists, if not creating the record. Also checking dependencies).

Issue: In the middle of an export process, we experience a failed call with a HTTP Status Code 401 returned with the following data:

{"message":"You are not logged in."}

This occurred after checking the status of a long-running ReleaseBill Action. This is the order of requests:

GET /entity/Default/18.200.001/Bill?$filter=... → OK

PUT  /entity/Default/18.200.001/Bill → OK

POST /entity/Default/18.200.001/Bill/ReleaseBill → Accepted

GET /entity/Default/18.200.001/Bill/ReleaseBill/status/{id} → Accepted (few times)

GET /entity/Default/18.200.001/Bill/ReleaseBill/status/{id} → No Content

GET /entity/Default/18.200.001/Bill?$filter=... → Failed 401  (same request parameters as the first GET /Bill)

 

The Access token was good for another 30 minutes and was able to be used for additional exports and manual Postman requests before renewing it.

 

Any ideas on why we received the 401? Is it possible to trace the REST API calls from the Acumatica instance?

Hello!

Maybe you will find How API requests are handled in Acumatica ERP 2019 R1 and later article helpful.


Irina,

 

Thanks for the link to article. After reviewing the flow chart, my issue doesn’t quite fit the flow - per the flowchart, the 401 response would indicate the session is not still alive - but a) the session was established less than 5 minutes to receiving the error, and b) immediately after the error my service was able to make API calls with the same token successfully.

What is anomalous when reviewing the API calls is that when the call fails to 401, the response to the previous request took longer to respond, e.g. when GETting a bill status successfully, the response was returned in less than an second, but when it took longer, (3-5 seconds), the next (unrelated) API call failed. I’m aware that doesn’t specifically help, but something I observed when live monitoring the requests via Fiddler (cloud service running via Azure Compute Emulator).


Reply