I figured, I can set alarm’s state via update of an alarm (PATCH method of /alarms/{id}) and theoretically get the closed state’s guid from /alarmStates where I can look for the matching name of the state. Would it be the recommended approach?
Yes, what you describe is the correct way.
You might have seen the documentation of the alarms PATCH here - https://doc.developer.milestonesys.com/mipvmsapi/api/alarms-rest/v1/#tag/Alarms/operation/Alarms_Patch
As you see there are five required fields to the patch.
As you mention you should look up the possible states and find and use the closed state.
/api/rest/v1/alarmstates
You should look up the possible priorities and use the best applicable.
/api/rest/v1/alarmpriorities
You should look up the reasons for closing and use the best.
/api/rest/v1/alarmclosereasons
The last two, comment and assignedTo.displayName, are strings that will not be evaluated and can be empty strings
Example from my test setup.
I thought it strange that you should give at ‘reasonForClosing’ event if changing the state to something else like ‘On Hold’. Now I realize that you can put ‘reasonForClosing’ to null.
Perfect, thank you so much for the detailed answer!