Improvement to objects lifecycle with Devolutions Server REST APIs
Improvement to objects lifecycle with Devolutions Server REST APIs
3 votes
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!
All Comments (8)
Hello,
Creating RDPConfigured and WebBrowser entries through POST /api/v1/vault/{vaultId}/entry is supported since DVLS 2025.3, along with PUT and PATCH. If you are getting a 422 on those two types, please confirm your server version, and make sure you do not send a subType for them (it must be omitted). PATCH for metadata (name, description, path, tags) also works.
The remaining gaps you listed are real, and we have opened an internal improvement ticket to address them. We will update this thread when there is progress.
Best regards,
Sébastien Aubin
Product manager - Password Management
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,
could you provide any updates regarding the ticket opened for this feature request?
Thanks!
Hi, i've updated the priority of this ticket. We'll let you know as soon as it's available.
Best regards,
Sébastien Aubin
Product manager - Password Management
Hi,
Thanks for your patience, and sorry for the delay. I dug into this in detail and split your request into two tickets.
1. Fixes for RDPConfigured and WebBrowser entries (done)
While testing, I found that part of my previous answer was wrong, and I apologize for that:
- Omitting subType on POST /api/v1/vault/{vaultId}/entry returned 422 for RDPConfigured and WebBrowser entries, which was the opposite of what I told you.
- host/port (RDP) and url (Web) sent in data were silently ignored: the call succeeded, but the values were not saved or returned.
- PUT/PATCH on WebBrowser entries returned 422, including for entries created in RDM.
All three are fixed. With the fix:
- subType can be omitted.
- host, port and url can be set with POST, PUT and PATCH, are returned by GET, and appear in GET /api/v1/entry/definition.
- For WebBrowser entries, subType can name the browser (for example Edge).
The fix will be included in an upcoming DVLS release. Until then, you can create RDP and Web entries by sending "subType": "" explicitly, but host and URL can't be set through the API yet.
2. The rest of your request (in development)
The second ticket covers:
- setting and changing the linked credential (credentialConnectionId) on session entries, with validation of the referenced credential and your permissions on it;
- creating Aws and DataReport entries through the API, and adding them to GET /api/v1/entry/definition.
This part is larger because it touches credential links and secret handling, so it goes through a security review. I'll update this thread when it's available.
Thanks again for the detailed report. It helped us find these issues.
Best regards,
Sébastien Aubin
Product manager - Password Management
Hi,
Thanks again for the detailed request. Part of it is now available in Devolutions Server 2026.3.13.0:
- RDPConfigured and WebBrowser entries can now be created with POST without passing a subType. Previously, leaving it out returned a 422.
- PUT and PATCH now work on WebBrowser entries.
- host and port (RDP) and url (WebBrowser) can now be set with POST, PUT and PATCH. They are also returned by GET and listed in /api/v1/entry/definition.
This also corrects our earlier reply: before this version, omitting subType failed, and PATCH did not actually update host or URL.
The rest of your request isn't in this release: setting the linked credential (CredentialConnectionID) through the API, and support for the AWS and DataReport entry types. These need more work, including a security review, and should come in an upcoming version. We'll update this thread when they're available.
Best regards,
Sébastien Aubin
Product manager - Password Management
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.
Hi, the remaining feature will be available in the next minor release of DVLS.
Best regards,
Sébastien Aubin
Product manager - Password Management