I looked into this around the start of 2024 and it was not possible. The workaround is you can run a script on the VTSCADA host that queries the historian via the VT SCADA REST API (which exposes a sql-like interface to tag history), which then uses its own http client to do the HTTP POST. If you call this script via the Windows Scheduler, you can do it e.g. every minute, every 5 minutes, etc.
Of course, now you have to maintain the script. It needs permissions to run unattended, and probably access to secure data (e.g. API keys) to do its work. If tag names change, your VT SCADA REST API queries will likely need to be maintained.
Another option worth exploring (I have not achieved this myself but it should work) would be to use a MQTT broker along with the new VTSCADA MQTT client driver. From the MQTT broker, you should be able to configure delivery of an HTTP POST for every event sent via the VTSCADA MQTT client driver.
I looked into this around the start of 2024 and it was not possible. The workaround is you can run a script on the VTSCADA host that queries the historian via the VT SCADA REST API (which exposes a sql-like interface to tag history), which then uses its own http client to do the HTTP POST. If you call this script via the Windows Scheduler, you can do it e.g. every minute, every 5 minutes, etc.
Of course, now you have to maintain the script. It needs permissions to run unattended, and probably access to secure data (e.g. API keys) to do its work. If tag names change, your VT SCADA REST API queries will likely need to be maintained.
Another option worth exploring (I have not achieved this myself but it should work) would be to use a MQTT broker along with the new VTSCADA MQTT client driver. From the MQTT broker, you should be able to configure delivery of an HTTP POST for every event sent via the VTSCADA MQTT client driver.