Introduction
Following the introduction of the new HTTP Request activity in the WebAPI 2.0.0-preview activity package:
We have now released the next preview of the WebAPI package 2.1.0-preview with even more features. Read more about them below 
Release notes
HTTP Request activity
Improvements
Improved UX for Handling Response Files in HTTP Request Activity
The Http Request activity now offers improved user experience and enhanced control when saving file responses.
A new Response Options section has been added, allowing users to:
- Specify a custom file name (defaults to the name from Content-Disposition, if available)
- Choose a target folder for saving the response file (defaults to the Current Project Folder instead of Downloads)
- Define behavior for file name conflicts, with options to:
- Auto rename (default)
- Replace
- Stop and discard
- The logic for detecting file responses has also been significantly improved, making it more reliable and resilient — even in cases of non-standard or misconfigured server responses.
Added Negotiated Authentication Support
We’ve introduced Negotiated Authentication to extend support for enterprise-grade security protocols.
- Supports Kerberos, NTLM, and Digest under a single option
- Automatically uses the appropriate mechanism depending on the environment
- On Windows, works with either OS credentials or manually provided domain/username/password
- On Linux/macOS, relies on system Kerberos tickets (e.g., via kinit); manual credentials are not supported
- This enhancement makes it easier to securely connect to systems that rely on integrated authentication — with no additional setup required in most cases.
Note:
Basic and Bearer authentication methods were already supported and remain unchanged in this release.
Bug Fixes
- Resolved an issue where Basic Authorization - Secure password and Client certificate secure password secure strings were disposed too early. This caused a runtime exception: Cannot access a disposed object. Object name: ‘System.Security.SecureString’.
- Added validation to check the length of the request URL before sending HTTP requests. If the constructed URL (including parameters) exceeds 2,000 characters, the activity now fails with a clear, user-friendly error message.
- Fixed an issue where switching from a “Local file” to a “Resource file” without clearing the local field could still send the local file instead of the resource one when using a “Stream” body type.
- Fixed a bug where setting the Content-Type header with a charset parameter (e.g., application/json;charset=UTF-8) caused an exception. The Content-Type header now correctly supports values with charset and other parameters.
- Fixed an issue where passing a full cookie header (containing multiple cookies separated by
;character) as a single cookie value to the Additional cookies collection would throw an exception. The implementation now normalizes and adds such cookies, ensuring that they are parsed and stored individually, consistent with browser behavior.
Breaking Changes
Headers Collection Now Uses Dictionary
- The Http Request activity has changed how headers are managed to improve consistency and prevent invalid duplicates.
- The Headers collection has changed from List<KeyValuePair<string, string>> to Dictionary<string, string> and now uses the Dictionary widget.
- Each header key must be unique.
- If you previously relied on adding the same header multiple times, you should:
- Merge values into one entry, or
- Clear the collection before updating.
- This update ensures more predictable behavior and avoids sending duplicate headers that could cause issues.
SOAP Client activity
To better support Legacy to Windows project migration scenarios, we have introduced a new SOAP Client activity that allows projects using the legacy WCF-based SOAP activity to be migrated to Windows compatibility with minimal changes.
Note:
To upgrade to this activity, first convert your legacy workflow to a Windows workflow, and then upgrade the WebAPI package to version 2.1.0-preview or later.
You will not be able to add this activity in new workflows, as it is meant to replace any existing SOAP Request activities only.
Highlights
- Maintains the same interface and parameters as the previous SOAP activity, ensuring existing workflows continue to run without redesign.
- Supports both SOAP 1.1 and SOAP 1.2 services.
- Automatically reads service metadata (WSDL) when available, making it easier to connect to standard SOAP endpoints.
- Provides support for authentication (Basic and Windows credentials) and client certificates.
- Ensures a smoother migration path from older projects to modern Windows-based projects.
This delivery paves the way for a future release of a brand new SOAP activity with extended functionality and advanced capabilities, that will be made fully available to our users.
Please tell us what you think
Which features excite you the most and are you going to try right away? We want to hear what you think! Please use the 
button below
