How credentials are protected

Connecting a tool means handing Nodest a credential — an API key, an OAuth token, sometimes a password. Here's what happens to it.

Encrypted before it's stored

Every credential is encrypted before it reaches our database, using strong industry-standard encryption. API keys, passwords, and OAuth tokens are all treated the same way.

Anyone with direct access to the database sees only encrypted values. The key needed to read them is kept separately.

Decrypted only to be used

A credential is decrypted at a single moment: when a step in your automation authenticates against the tool it belongs to. It's used for that request and nothing more.

Credentials never appear in run history. When you inspect a run, you see the data that moved between steps — never the key that authorised the call.

They can't be read back

Once saved, a credential can be replaced but not retrieved. No screen in Nodest shows an API key you entered earlier, and support can't look one up.

That's deliberate — a credential nobody can read is a credential nobody can leak. It does mean keeping your own copy of anything you might need again, in whatever password manager your team uses. If it's lost, generate a new key in the tool and reconnect.

OAuth connections never see your password

Where a tool supports OAuth, connecting sends you to that tool's own login screen. You sign in there, and Nodest receives a token limited to what the integration needs.

Your password for that tool never passes through Nodest at all. Revoking access from the tool's side invalidates the token immediately, with nothing to change here.

Your Nodest password

Your password is stored in a hashed form that can't be turned back into the original. Nobody at Nodest can see it — not support, not engineers — which is why a forgotten password is reset rather than looked up.

In transit

Traffic between your browser and Nodest, and between Nodest and every tool you connect, runs over HTTPS. Credentials are never sent over an unencrypted connection.

What you should still do

Encryption protects a credential where it's stored. It can't make a credential less powerful than you made it.

Scope keys narrowly. If the tool lets you issue a key limited to what the automation needs, use that rather than an admin key.

Use a service account where it matters. A key tied to one person breaks when they leave; one tied to a shared service account doesn't.

Rotate after a departure. Someone who left with a copy of a key still has it, however well it's stored here.