The supplier of the webservices we are consuming have a lot of custom headers in the HTTP call itself, not in the HTTP Body where the SOAP headers lie. In the current functionality you can add username and password to the HTTP headers, but this doesn’t suffice for our need. We need to SHA256 hash the entire body and add this as a header, then we need to add several identifying headers like an organizationId, a userId, the IP we are sending the request from, a timestamp, the target destination, etc. Then all the headers must be packed into a string and RSA SHA256 signed and added as a final header. This is an implementation of this HTTP signature standard with a few specialized extra headers. If we don’t sign our http packets we don’t get through the security features of the back end system and are not able to run the soap webservice. When I’ve been researching this I’ve found several forum posts that need something similar, i.e. this one but your support has confirmed to me that this isn’t possible. The solution we have chosen is to make a program and import it as a dll that acts as our own proxy that does all of this and sends the http call for us and return it into blue prism as a string. But then we must run the wsdl through an external tool to make our own SOAP calls, and parse the resulting soap xml ourselves and make our own error handling each time. This is time consuming and error prone, so it would have been very nice if we could have added these headers to the HTTP call similarly to how we can do it for REST APIs. Preferably we would have wished that you implemented the signing standard directly, that would have saved us from even more work. ... View more