I have come across this issue a few times now, and feel it's worth bringing up. A major roadblock to making our integrations (with major platforms like ConnectWise) work the way we want them to is the limitation of only being able to make a single API request per event/status change/etc. One example - we want to be able to insert the "Acknowledged" notes when an alert (or several) are ack'ed in LogicMonitor as a service note to the corresponding tickets in ConnectWise AND update the status of the ConnectWise ticket to 'In progress'. That requires 2 API calls: one (which is the default for your builtin ConnectWise integration) to update the ticket priority/status/etc (HTTP PATCH -> https://{connectwiseSite}/v4_6_release/apis/3.0/service/tickets/{id}) and another to add a note to the ticket (HTTP POST -> https://{connectwiseSite}/v4_6_release/apis/3.0/service/tickets/{id}/notes). Another example - our RMM tool does not support the usual API Key method of authentication. It requires that one go through a slightly obtuse algorithm to send credentials, save a generated session token that is returned as part of the response body, and then submit that session token in the headers of future requests as a bearer token. I don't want to just leave these sessions open all the time, even though all traffic is submitted through HTTPS, the session token grants access as the API user from anywhere. So without going bonkers in complexity and asking for the world - it would be good enough to just be able to execute multiple API requests : 1 - Authenticate and save part of the response body, 2 - Submit one or more requests using the session token, 3 - Logout. We /really/ need the ability to get information from LM into ConnectWise and other platforms to make this solution shine.

As a precise example as to why this would be a useful feature: vCenter alarms SNMP trap notifications. At least in my experience these are sent from vCenter as v1 traps but all the juicy information is in the trap variable bindings. Here's a trap sent from a CPU Usage Alarm: 1.3.6.1.4.1.6876.4.3.304.0: Green 1.3.6.1.4.1.6876.4.3.305.0: Red 1.3.6.1.4.1.6876.4.3.306.0: alarm.VmCPUUsageAlarm - Metric CPU Usage = 100% 1.3.6.1.4.1.6876.4.3.307.0: SERVER-1 1.3.6.1.4.1.6876.4.3.308.0: 3 enterpriseOid: 1.3.6.1.4.1.6876.4.3 generalCode: 6 snmpVersion: v1 specificCode: 203 sysUpTime: 1778505188 trapVariableBindingCount: 5 All the /really/ useful information is in the trap variables: 1.3.6.1.4.1.6876.4.3.304.0 (vmwVpxdOldStatus) 1.3.6.1.4.1.6876.4.3.305.0 (vmwVpxdNewStatus) 1.3.6.1.4.1.6876.4.3.306.0 (vmwVpxdObjValue - What alarm got tripped!) 1.3.6.1.4.1.6876.4.3.307.0 ( vmwVpxdTargetObj - What vCenter object tripped the alarm!) Being able to filter on the contents of bound variables, and address them as tokens in alarm subject/message, as something like ##TRAPVAR01##, ##TRAPVAR02##, ##TRAPVAR03## would be a massive workflow improvement for us.