Neophyte
ProfessorOne trick that can help is that the portal itself uses the API. So you can set in SDT in the portal and watch the Networking tab of the Browser's developer tools to see the request and parameters. Like here is what I got when doing a 1 hr SDT on a device:
{"deviceId":100,"type":"ResourceSDT","sdtType":"oneTime","startDateTime":1715093520000,"endDateTime":1715097120000,"timezone":"America/New_York","comment":"test"}
P.S. The portal does sometimes use undocumented or functions that are not in the API. But most day-to-day stuff uses the same API.
NeophyteHa! Yeah I'd think it'd be important to include 'deviceId' in the swagger docs. My main skill set is not developer related so I rarely think about dev tools like that. Good call.
ProfessorYeah, that is very odd that it's missing from Swagger. I also thought that Swagger was auto generated from code so I'm not sure how it can miss it. I've never used it outside of vendor API references so perhaps I'm wrong on that.
Well, it does say "Response may contain extra fields depending upon the type of SDT being added". The thing to understand about swagger is that it's machine generated based on the source code. And SDTs are weird because the request is different depending on the target of the SDT. Since swagger doesn't know all those variations, it doesn't know to document it. LM should do a better job of enhancing the machine generated documentation with examples and use cases.
That said, i was going to suggest exactly what Mike_Moniz suggested: look at the calls the browser makes. The only caveat to that is that parts of the UI have started to use APIv4, which in most cases is backwards compatible with v3, but not always. Still, if the swagger is incomplete, that's the next best thing.
