N8n API Add functions for credentials


I would like to suggest adding some functions in the API in order to be able to manipulate more easily the crendetials
1°) updateCredentials - (By Name / By Id)

This function would allow to update the existing credentials in case of key or password rotation in the applications.

Use case:
RabbitMQ : credentials are managed by Hashicorp Vault, a key rotation is active, credentials expire after a certain time
In n8n, with the id or the name of the credentials we could update the login information directly.

Currently, there is no choice but to create a new credential, and delete the previous one.

2°) getAllCredentials

This function would allow to list all credentials, without returning confidential information. The purpose of this function would be to search for a credential in the database and to retrieve its id/name in order to update it.

Use case:
A credential needs to be updated. The API would allow to list the APIs. With this list, we could find the desired credential, retrieve its Id and use the previous API (updateCredential) to update it.

Currently, there is no way to get the ID of a credential
In fact, I also wonder about the usefulness of the delete credentials by Id function, if we can’t have an id in a programmed way. We absolutely need to know the Id in a “manual” way

Why these function : Nowadays, computer security is becoming more and more important. Many systems are starting to implement secret rotation mechanisms through applications such as Hashicorp Vault.

The implementation of these features would allow more flexibility for n8n nodes.


I can see the public API was only merged in June this year - nicely done! I would like to add a use case for getAllCredentials AKA a GET /credentials endpoint.

I’m currently using n8n to integrate firefly-iii and grist-core. I did it using an n8n workflow, but I also made a grist widget that gives the user control over the integration (via the workflow itself and the n8n API). One of the widget’s functions will be to install the n8n workflow inside n8n, then invoke the workflow to configure firefly-iii webhooks via its API. This needs a firefly-iii API key and a Grist API key to work, and ideally I’d like these to be stored and configured in n8n, not the user’s Grist document or widget settings.

To install the workflow in a user-friendly way, the user needs to be able to select which credential to use for grist and firefly-iii via the widget. It would be nice to populate a dropdown using a new endpoint GET /credentials .

That would be very useful! Patch should be available through api.

Also a little more documentation would help. I used my chrome devtools to inspect a manually created credential to be able to identify what should i put on the “type” required field do create a new credential.

Merry Christmas. Here is a PR for a GET /credentials endpoint


@Jon @MutedJam @jan @RicardoE105 - please could you get someone to take a look at my PR?

Hey @johncant,

I will create an internal ticket for a review but typically core changes take longer to consider as it has potential to impact features we are planning to work on.

At the moment if your PR solves the issue you currently have you can make a custom image from it and use that until we have completed a review and decided if we will accept the PR.

I would also try to not tag a bunch of us in a reply as we already have notifications configured and can see what is happening :slight_smile:

1 Like

Hi @Jon - thanks a lot!

Hi @Jon - do you have any update?

I notice it’s been so long the base branch has changed quite a lot and there are now some conflicts.

Wondering whether it’s worth investing my time resolving them and getting the PR mergeable again. Normally when submitting PRs to an active project, the changes either get merged, or you get reasons as to why they can’t be merged. Very unexpected to see what looks like complete apathy towards this feature added by a member of the community.

Seems like there was some sort of approval gate for the CI to run - and no-one even approved that!

1 Like

Hey @johncant,

It looks like this has not been picked up yet there are a few API changes that need to be reviewed but it all comes down to the priority and availability for someone in that team to review it.

The approval for the CI process happens when we review it and I suspect we will get to this one it is just a case of when. Our PR process for core changes does need some work so that we can get through the backlog of requests there though as there a good chunk of things that could be useful.