REST API returning empty set for some object types

If you’re logging in with your login then you should be governed by your login’s security.

What is the URL are you’re using for the SalesOrder call?

I’ve tried:

{our site}/entity/Default/18.200.001/SalesOrder/006277

which generates: "exceptionMessage": "Operation is not valid due to the current state of the object.",

and

{our site}/entity/Default/18.200.001/SalesOrder?$filter=OrderNbr eq '006277'

which returns []

In fact, 
/entity/Default/18.200.001/SalesOrder?$top=7

returns []

SalesOrder has a two part key so if you want to use a direct URL you need to split out the Order Type:

{our site}/entity/Default/18.200.001/SalesOrder/SO/006277  (under the assumption your order type is SO)

What if you leave out the filter? Just end your GET call URL with (make sure you’re using GET)

/entity/Default/18.200.001/SalesOrder

Do you get anything returned?

Oh - and do you have more than one Tenant in this database?

​@PSchirf61 do you use the same user for UI and API? 

Also, I’d recommend you to use a newer API version, e.g. 22.200.001 instead of 18.200.011. 

No, I do not use the same user.  My “normal” user can see the data.  The API user has the issue described above.  I mentioned the normal user to indicate that the data exists.

https://xeroshoes.acumatica.com/entity/Default/18.200.001/SalesOrder 

returns 200 OK with no data: []

https://xeroshoes.acumatica.com/entity/Default/18.200.001/SalesOrder/SO/006277

returns  "exceptionMessage": "No entity satisfies the condition.",

With my normal user, this sales order exists:
/(W(1))/Main?CompanyID={our company ID}&ScreenId=SO301000&OrderType=SO&OrderNbr=006277

Yes, this was a permissions issue, which is a little strange.  I would have expected a permissions issue to return a message that I lacked permission to a specific data type/object, but instead got an empty set. 

​@PSchirf61 what was the permission(s) that were missing?  I’m having an issue with API calls that used to work but no longer work after an upgrade.  Thanks.

​@PSchirf61 figured it out.  it was due to the user type not having the permissions for the branches and then setting those on the user account being used in the API.  Instead of throwing error, it just comes back empty because even though that user has access to the screen, it did’t yet have access to the contents of the screen.

Thank you for sharing your solution with the community ​@ggnabasik47!

Looking at response headers for a clue to empty responses is a good debugging tool.