Improvement to objects lifecycle with Devolutions Server REST APIs

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!