Devolutions - Can invoke on GET but not POST

Devolutions - Can invoke on GET but not POST

avatar

Hi Team,

I have created an application level account:

it has access to the necessary vaults.

In postman, I can get a token back as well as a GET request on the vault in question. However when I try to send a post in an attempt to create an entry, it says the vault does not exist:

LOGIN

GET Request on specific vault:

POST Request on the same vault:

Any ideas?

avatar

Recommended Answer

Hi Joseph,

Thanks for testing on 2026.3.7.0, and no worries about the delay. The change in the message is good news: the vault and permission part is now working, and the remaining error is only about the request body.

Yes, Credential entries can be created through the API. The request is missing one field: "subType". For a username and password credential it must be set to "Default". Without it, the server rejects the request with the "entry type is not supported for creation" message.

Here is your request with the field added:

{

 "name": "TEST Upload",

 "description": "wdw",

 "path": "",

 "type": "Credential",

 "subType": "Default",

 "tags": [],

 "data": {

  "domain": "your domain",

  "username": "hello",

  "password": "hello"

 }

}

Please keep "type" as "Credential" (singular), as you already have it. Please also send this to the same URL as before: /api/v1/vault/{vault id}/entry.

If you later need other kinds of credentials, the subType changes accordingly (for example "PrivateKey" or "ApiKey"). You can list the available types and subTypes with a GET request to /api/v1/entry/definition.

Please let us know if the entry gets created.

Best regards,

Alexis Geller Peiro

All Comments (9)

avatar

Hi @jfabrello,

Thanks for the details and screenshots, they're helpful.

Before we dig further, could you confirm a couple of things for us:

Product and version: This looks like the DVLS REST API. Could you confirm which version of DVLS you're running?

1. Application identity permissions on that specific vault

Having read access to a vault (which is what GET uses) doesn't necessarily mean the application identity also has write/create permissions on it. Could you check the "Vaults" tab and the role assignments for this application identity, specifically for the vault with ID 3e232dc8-ad40-4da7-a3a6-c5d1ffd8ab7d, and confirm whether it has permission to create entries there (not just view them)?

For reference, here's our documentation on application identities: https://docs.devolutions.net/server/web-interface/administration/user-and-security-management/applications-identities

2. The URL variable used in your POST request

Looking at your screenshots, the Login and GET requests use {{base_url}} (lowercase), but the POST request uses {{BASE_URL}} (uppercase). Postman variables are case-sensitive, so these could be resolving to two different values. Could you check what {{BASE_URL}} actually resolves to in your Postman environment/globals, and confirm it points to the same server as {{base_url}}?

For reference, here's our REST API documentation, which also has a working sample script for login and requests: https://docs.devolutions.net/server/web-interface/utilities/api-documentation

One more note: the API v1 currently only supports creating entries of type Credentials via POST, other entry types aren't supported. Your request body already uses "type": "Credentials", so this shouldn't be the issue here, but flagging it in case it's useful.

Once we have these two confirmed, we can narrow down where the 404 is coming from.

Best regards,

Alexis Geller Peiro