Device DataSource Instance datapoint historical data using RestAPI v3

I’ve never been able to get postman to work right with LM’s API… even while taking the LMCD :)

I’ve just used my own code for it as a result.

With the move to Bearer Token for auth, you don’t need a prescript any longer. Which makes using tools like Postman or Insomnia that much easier.

For anyone else who has the same paranoid questions I do: Trust Center | Postman

The tradeoff is that they don’t state whether your api tokens are stored on device or in the cloud… so when they inevitably get hacked, the bad guys have access to your credentials… and I’ll take a peek through and see what that thread says for me, I know I did a bunch of trying and searching… but if I can’t find a statement of where the data is stored specifically (not just assurances of safety), then I can’t use postman, so it’ll end up as a moot point.

I’ve requested explicit statements of this from them as I didn’t find anything in their security documentation about storage locations for different types of data.  I’m paranoid about such things… but have been proven right over and over again throughout my career.  So… I’ll keep poking at it using the powershell code I’ve got.

There are other options. There are other rest clients that let you do rest calls all locally contained within the app or as an extension in your browser.

@Cole McDonald I personally use Insomnia.rest. It has a local electron app that I use.

While using Curl or Invoke-RestMethod is quick and easy. Sometimes it is just easier to click Go and see the structured data right there.

Specifically based on this:

For what it’s worth, you should be able to use the swagger docs themselves to test out API calls. However, this was never explored/explained/enabled by LM since the auth was too complicated for even swagger to decipher. However, now that bearer tokens are a thing, you should be able to put your bearer token into the swagger web page, provide the path and query variables for a call and run the call. That’s what the “Authorize” button is for at the top of the page (that they forgot to disable or couldn’t figure out how to disable). LM needs to turn on a couple flags when generating the swagger docs though (like the ability to specify the portal url, and the “execute” buttons that swagger normally offers), then it should be possible to run all the API calls you want right from the swagger docs.

Right, LM needs to flip some flags when they generate the swagger docs. I just put in a feed for it, but the more the merrier.

Really, there’s no reason, now that we have bearer tokens, to be able to do what swagger does in their example. Notice the “try it out” buttons on each call. 

Is there a way to get the DeviceDatasourceID as a built in variable from the platform?  That would save a ton of API overhead.  Then I can just grab the instances from that and get my historical data using the DDI’s properties.  I don’t find anything in the LM Docs that state this for use in dataSources, I do find them for alerts though.

I can get the deviceid and the instanceid, but not the datasourceid… from the restAPI, I can access the device and the dataSource, but not the instance… so I have to get the devicedatasource to get to the instance no matter how I slice it.  That adds an extra uneccesary API call that could be a single pre-filtered call.

I’ll put in a feedback for the direct instance access as I would prefer that since we seem to have that ID as an instance level token as ##system.instanceid##  I would expect there to be a ##system.devicedatasourceid## that we could reach now to get the necessary IDs for filling out the URL to the instance.

Confirmed absent thorugh the support team