uccloudteam

Hi @Sébastien Aubin,

Thank you for the implementation of these features and for the detailed update, it is really appreciated.

We look forward to the implementation of the remaining features (the ability to set the linked credential (CredentialConnectionID) through the API, and support for the AWS and DataReport entry types), as these are essential for us to complete the migration to Devolutions Server.

Thanks again for your support, we look forward to further updates.

Hello,

Since upgrading the RDM Windows client to 2026.3.15.0, Website objects no longer log in automatically. The username gets filled in, but then the autofill stops. The password field stays empty and the form isn’t submitted.

Before the upgrade, the same objects filled in both the username and the password and logged in automatically. I haven’t changed the entries configuration.

Environment

• RDM client version: 2026.3.15.0

• OS: Windows 11 Pro

• Credentials set in the Website object itself

• Web browser: Microsoft Edge (default setting)

Thanks

Hi,

could you provide any updates regarding the ticket opened for this feature request?

Thanks!

Hi,

Just wanted to follow up on this feature request and see if there are any updates regarding the ticket that was opened.

Thanks!

Hi,

Just wanted to follow up on this feature request and see if there are any updates regarding the ticket that was opened.

Thanks!

Hi,

I send this feature request as part of our ongoing evaluation of a potential migration to Devolutions Server. Being able to manage the full lifecycle of our vault entries programmatically through the REST API, rather than the PowerShell module, is an important aspect of this evaluation.

I would like to request support for creating and fully managing connection/session objects through the REST API, in addition to Username/Password credentials.

Based on our recent tests, we can already do the following through REST API v1:

• Create, read, update, move and delete folders

• Create, read, update and delete Username/Password Credential objects

• List and filter vault entries with pagination

• Rotate Web and RDP secrets by PATCHing the linked Credential object

However, creating the actual connection/session entries is not possible through the public REST API.

POST /api/v1/vault/{vaultId}/entry returns HTTP 422 for these entry types:

• RDPConfigured

• WebBrowser

• AWS (AWS Dashboard)

• DataReport

RDPConfigured and WebBrowser appear in GET /api/v1/entry/definition, so we expected them to be creatable via REST. AWS and DataReport do not appear in that definition at all.

Support confirmed that REST API v1 is currently designed around Username/Password credential management, and that session creation requires the PowerShell module. Because of this, provisioning new sessions still requires PowerShell even when folders and credentials can already be created via REST.

A related gap is linking: we cannot set CredentialConnectionID / CredentialConnectionSavedPath through REST when creating or updating a Web or RDP entry. Linking a connection to an existing Credential object currently requires PowerShell.

Ideally, REST API v1 would support:

• POST (create) for RDPConfigured, WebBrowser, AWS and DataReport entries

• The ability to set/update the linked Credential reference (CredentialConnectionID) on RDP and WebBrowser entries via REST

• PATCH of connection metadata for those same entry types (host, URL and other non-secret properties)

• Inclusion of AWS and DataReport in GET /api/v1/entry/definition, consistent with the types we can already list

This would allow us to onboard and maintain new objects entirely through REST, instead of mixing REST for folders/credentials with PowerShell import for sessions.

The switch to REST API is especially important for our use case, as we need these operations to be automated consistently through an external integration. REST would make these flows faster and more consistent than invoking the PowerShell module for every new object.

I believe this would be a valuable addition, particularly for environments where vault entry lifecycle management needs to be integrated with external automation and API-based workflows.

Thanks!

Hi,

I send this feature request as part of our ongoing evaluation of a potential migration to Devolutions Server, and the ability to manage credentials programmatically is an important aspect of this evaluation.

I would like to request support for linking an AWS Dashboard entry to a separate Credential object, similar to how Web and RDP entries currently work.

For Web and RDP entries, there is a Credential field in the Properties where I can select a separate Username/Password Credential object. The Credential object can also be manipulated through the REST API, which makes it possible to integrate credential management into external automation and workflows.

However, the AWS Dashboard entry does not currently expose a Credential field or any option to reference a separate credential object. Instead, the Access Key ID and Secret Access Key have to be configured directly in the AWS Dashboard entry.

I understand that AWS authentication is different from the generic Username/Password model. What would be particularly useful is having an AWS-specific Credential object (containing Access Key ID and Secret Access Key values) that could be linked to the AWS Dashboard entry and managed through the REST API.

Ideally, the AWS Dashboard would support:

• A dedicated AWS Credential object containing the Access Key ID and Secret Access Key

• A Credential field in the AWS Dashboard entry to reference that object

• Management of that Credential object through the REST API

The switch to REST API is especially important for our use case, as it would allow AWS credentials to be managed easily and faster rather than having to modify the AWS Dashboard entries using the PowerShell module.

The support team confirmed that this functionality is currently not planned for upcoming releases and recommended submitting it here as a feature request.

I believe this would be a valuable addition, particularly for environments where credential management needs to be integrated with external automation and API-based workflows.

Thanks!