API key

What the key identifies and what it does not identify

The term API key alone does not say who has been granted access. In Google Cloud, a standard key associates requests with a project for billing and quota purposes, without identifying the actor making them. An authorization key authenticates a request using a service account's identity and acts according to its permissions, so it must be kept secret. This is a distinction between Google key types, not a definition that applies to every provider.

Google warns against using authorization keys in production for APIs that create or manage resources in Google Cloud. The documentation describes an exception for the Gemini API, provided no IAM roles have been assigned to the service account associated with the key. This distinction explains the key type and is not a recommendation to choose it.

In Stripe, a publishable key is also intended for code that runs on the user's device, while secret and restricted keys must be kept secret. A restricted key lets you set permissions. Test environment keys are also separate from live environment keys. Check the service documentation to determine what type of key you have, not just the name of the field where you paste it.

A key shared across different workflows does not, by itself, show who ran each workflow. For useful usage records, include the workflow name, environment, and action result, without logging the key value.

Where to store it in automation

Store a secret key in the credentials mechanism of the automation tool or in an organization-approved secrets manager. The workflow should reference the stored item instead of copying its value into fields, sample files, or messages. In n8n, credentials are encrypted before they are saved to the database. Encryption at rest is not permission to print them during execution.

Google recommends restricting keys and keeping them out of client code and code repositories. In the Google APIs documentation, it also recommends avoiding passing the key as a URL parameter. For another provider, follow its documented authentication method and distinguish a secret key from one it explicitly identifies as publishable.

Record the name of the entry in the credentials mechanism and the action the connection needs to perform in the inventory. Where the service supports it, tailor permissions to that need. If a workflow only needs to read documents, check whether the provider lets you restrict it to read access before also granting it permission to make changes.

How to replace a key without missing a dependent workflow

For a planned replacement, start with a list of workflows that use the key, including scheduled jobs and test environments. Check whether the provider allows the old and new keys to work at the same time. There is no standard overlap period across all services. Stripe documents a gradual transition and checking usage of the old key before it expires.

After the authorized owner makes the change, check that access works in every dependent workflow and that the expected result was read or saved. Prefer a read-only check where possible. You do not need to send a customer a message or create a real charge to prove the key works. A scheduled workflow that has not run yet has not been checked.

Plan in advance what to do if the transition fails: stop in a controlled way, fix the configuration, or use a recovery method supported by the provider. Reverting to the old key is possible only if it is still valid and has not been exposed. After revocation, do not assume that restoring a configuration file will make it work again.

What to check when a key is exposed

Exposure of a secret key is an incident that requires urgent handling. According to OWASP, an exposed key should be revoked quickly. Notify the service owner, identify dependent workflows, and handle revocation and replacement according to the incident procedure. Do not wait for a complete inventory while unauthorized use is possible; workflows may need to be stopped temporarily.

Deleting the key from a message or file does not revoke its access. Check the key status and usage logs with the provider, and keep a redacted record of what you find. A revocation check may include a safe read request with the old key, performed only by an authorized person and according to the provider's documentation. A generic error by itself is not proof that the key was revoked.

Document the plan, the replacement that was performed, and evidence that the new key works and the old one no longer grants access, separately. All execution fields in the attached card are blank: it is intended for preparation and documentation, and does not indicate that any system was checked.

Ownership and permissions card to fill in

Copy the card for each connection into an internal copy with restricted access. The public table and download file are blank. Even an inventory without secrets may reveal internal structure, so share only a redacted copy outside the team.

No replacement, revocation, or access check was performed here. Fill in results only after performing and checking the work.

Business process example

A document processing workflow receives a dedicated key for a service. The key is stored in the credentials mechanism, and the workflow uses it without printing it in logs or passing it into content sent to a model.

1. Record who is responsible for the connection, which environment it runs in, and what action it needs to perform.
2. Select the saved credentials item in the workflow, and check that no copy of the key appears in the document content or run output.
3. Before replacement, also map the scheduled job that uses the same connection. After an approved replacement, check its result separately.

This makes it possible to know what else still needs checking even if the document processing workflow has already succeeded. This is an illustrative example, not a record of a connection that was set up.