Credentials and API keys

Guides
On this page

A credential groups access reused by nodes: an API key, token, service account, database connection or SSH key. Define the intended operation and resource first: they determine which permissions to grant.

Choose the right type

Open the node page and follow Credentials and prerequisites. The type must match the connector’s requirement, rather than just the service name.

  • Send or receive email: SMTP is for sending; IMAP is for receiving.
  • Call Stripe or receive its events: an API key and a webhook signing secret serve different purposes.
  • Query PostgreSQL or a vector index: PostgreSQL and pgvector connections are offered for different nodes.
  • Use an AI model: check the credential provider and access to the model selected by the node.

Procedures under Keys and connections list the required fields. They link to official references for provider-specific steps.

Create and use a credential

  1. In your nodulz instance, open Credentials and select the required type.
  2. Use a name that identifies the service, purpose and environment, such as CRM - read - test. Do not put a secret in the name.
  3. Complete the form. Check the host or URL, account, region, port and TLS where these settings exist.
  4. Choose the necessary sharing, then save. A shared credential does not automatically grant permission to edit it.
  5. Select the credential in the node and run the connection test if offered.
  6. Then test the exact operation on a test resource. A successful connection does not prove permission to create, update or delete that resource.

Separate test and production access. Grant the permissions needed for the operation, and use a service account when the provider supports one.

If the credential is missing

Check its type, owner and sharing. The workflow owner must be able to use the access: being able to open or edit a workflow is not enough to infer permissions on every credential.

If several credentials have similar names, choose the correct environment. Updating reused access can affect several workflows; identify its uses before changing it.

Connection and authorization

Use the service message to choose the next check:

  • Authentication rejected: check the secret, expiration, revocation and expected authentication type. A 401 status may point to this cause.
  • Operation forbidden: check permissions, account, project and resource sharing. A 403 status may point to this cause.
  • Resource not found: also check the environment, region and resource identifier; recreating a key does not fix the wrong destination.
  • Connection unavailable: check networking, DNS, host, port and TLS from the environment running nodulz, rather than only from your browser.

Exact codes and messages depend on the provider. Read its procedure and troubleshooting before changing several settings at once.

Rotation

  1. Identify workflows and environments using the current access.
  2. Create new access with the provider and grant the necessary permissions.
  3. Update the nodulz credential, or create a separate credential if workflows must migrate gradually.
  4. Verify a representative operation for each use, including a real event if the access is used by a trigger.
  5. Revoke the old access with the provider once checks are complete.

Share an example or logs

Keep secrets out of ordinary text fields when the node offers a dedicated credential. Do not copy keys into prompts, shared examples, screenshots or logs. Also inspect headers and URLs that may contain a token before sending a trace to support.