How tools authenticate

Every tool decides how it lets outside software in, so the method you see when adding a connection is set by the provider, not by you. Nodest supports five, and knowing which one you're dealing with explains most of what happens afterwards — including why connections break.

Method	What you provide	Typical of
OAuth	Approval on the provider's own screen	Most modern SaaS tools
API key	A key you generate in the tool's settings	Developer-oriented tools
Username and password	Credentials the provider issues	Older APIs
Application password	Site URL, username, application password	WordPress sites
Inherited	Nothing — it uses another connection	WordPress plugins

OAuth

You're sent to the provider's own login screen, you approve the access Nodest is asking for, and you're returned to Nodest. Your password is never typed into Nodest and never stored by it.

What you get back is a token, and tokens expire. Nodest renews them in the background, so a working OAuth connection generally keeps working without you touching it.

What breaks it: revoking Nodest's access in the provider's settings, or an administrator removing the account's permissions. Both require reconnecting.

Worth knowing: the connection carries the permissions of whoever authorised it. If that person's own access is later reduced — or they leave — the connection can start failing on things it used to do. For shared tools, authorise with an account that isn't tied to one individual.

API key

You generate a key in the tool's settings and paste it into Nodest. Simple, and it doesn't expire on its own.

What breaks it: regenerating or deleting the key at the provider. The old value stops working immediately, so reconnect with the new one.

Worth knowing: keys often carry scopes or permissions chosen when they were created. A key generated as read-only will fail the moment an automation tries to write, and the error comes from the provider rather than from Nodest.

Username and password

Some older APIs authenticate with credentials sent on each request. You enter them once and Nodest stores them encrypted.

What breaks it: a password change at the provider.

Application password (WordPress)

WordPress has its own mechanism for this, and it's the one to use — never your normal login password.

You generate an application password in the WordPress user profile, then give Nodest the site URL, the username, and that password. It's revocable on its own, so removing Nodest's access doesn't disturb the account itself.

What breaks it: revoking the application password, the site moving to a new URL, or the site becoming unreachable from the public internet. Security plugins and firewalls are the usual culprit for the last one.

See Connecting your WordPress site for the full setup.

Inherited

Some integrations don't authenticate on their own at all — they run on another connection.

WordPress plugin integrations work this way. WooCommerce, Gravity Forms, MemberPress and Easy Digital Downloads all use the connection to the WordPress site they're installed on. You authorise the site once and its plugins become available with no separate credentials.

If you add one of these before the site it depends on, Nodest tells you which connection is needed first.

What breaks it: whatever breaks the parent. Fix the site connection and everything inheriting from it recovers at the same time.

Is the connection verified?

Yes — Nodest tests every connection as you save it, using the credentials you just supplied. Wrong key, wrong password, unreachable host: you find out immediately rather than when an automation fails at 3am.

How are credentials stored?

API keys, passwords, and OAuth access and refresh tokens are encrypted at rest. Traffic between Nodest and your connected tools runs over HTTPS. See Data residency for where that data is held.