Where Should API Keys Live in a No-Code Automation Stack?

Where should API keys live in a no-code automation stack?

API keys belong in the credential store of the tool that uses them, never pasted into a step, a note, or a shared doc. In Zapier that means app connections. In Make it means keys and keychains. In n8n it means credentials. Then decide who can use each one, and write that down.

When I audit an automation stack, one of the first things I look for is a key sitting somewhere it should not be. A token pasted into the body of an HTTP step. A password in a Slack message from the week the automation was built. A spreadsheet tab called "keys" that three former contractors still have access to.

None of these feel dangerous on the day they happen. They feel like a shortcut to get something working before a demo. The problem is that shortcuts in automation stacks do not get cleaned up. They become permanent, and the person who made them leaves.

Why does it matter where a key is stored?

A key is a password that never asks for a second factor. Anyone who can read it can act as your CRM, your email tool, or your enrichment provider. Where it lives decides who can read it, who can change it, and whether you can find every place it is used when it needs to be rotated.

The automations I build sit close to revenue. A HubSpot key can create, edit, or delete contacts and deals. An outbound tool key can send email from your domain. An enrichment key can spend real money. That is a lot of power for a string of characters someone copied into a text field.

Storage also decides how painful rotation is. If a key lives in one credential and every workflow points at that credential, rotation is one edit. If it was pasted into twelve steps across five scenarios, rotation is an afternoon of hunting, and you will probably miss one. I wrote about the rotation side in how to rotate API keys without breaking your Zaps.

How does Zapier handle app connections?

Zapier stores access to your tools as app connections. Its help center says connections are private by default, so only you can use that app account in Zaps. On Team and Enterprise accounts you can share a connection, which lets others use it in their own Zaps without needing your login.

That default is good. The risk comes from what sharing allows. Zapier's help docs say people you share a connection with can view data used to test a Zap, use the shared connection in their own Zaps to access or update information, and edit steps in a team Zap that uses it. That is broad access, and it should be granted on purpose.

Zapier's own advice is to share connections only with people you are comfortable giving access to, and to consider a separate shared account in the app, such as one tied to a company email, instead of your personal account. I agree completely. A connection tied to one employee's personal login becomes a problem the day that person leaves.

There is also an operational detail worth knowing. Zapier's docs say that if a Zap owner loses access to a connection, the Zap pauses and stops running until access is restored or the step is switched to another connection. Plan for that before you remove someone, not after a revenue workflow goes quiet.

How does Make handle keys and keychains?

Make keeps credentials in a dedicated Keys section under Credentials. Its help center says the HTTP app saves the credentials you provide as a keychain for API key and Basic Auth authentication, and that the Encryptor and SSH apps use stored keys too. Use these instead of typing keys into module fields.

The reason is simple. A key typed straight into a module lives inside that scenario. Anyone who can open the scenario can see it, and it travels with every copy or blueprint export. A key stored as a keychain lives in one place, and modules reference it.

Make's docs also say that when you delete a key that scenarios use, you see a warning listing those scenarios, and after you confirm, the key is removed from all the modules where it is used. That warning is useful as an inventory tool. Before you rotate, it tells you exactly what depends on the key.

If an API wants a key somewhere a keychain cannot place it, stop and think before you paste it raw. Sometimes the right answer is a different module, or an app connection built for that service. Sometimes it is a small proxy you control. Pasting it into a body field because it works is the shortcut that never gets undone.

How does n8n protect stored credentials?

n8n saves credentials in its own credential store and encrypts them before they reach the database. Its docs say n8n generates a random encryption key on first launch and saves it in the ~/.n8n folder, and that you can set your own key with the N8N_ENCRYPTION_KEY environment variable instead.

For self-hosted teams, this is the part people skip. If the encryption key lives only in that default folder on one server, it is now a single point of failure. I set N8N_ENCRYPTION_KEY explicitly and store that value in the team's password manager, so a rebuilt server can still read its own credentials.

n8n's docs also note that in queue mode you must specify the encryption key environment variable for all workers. If you scale out and forget this, workers will not be able to use the credentials the main instance saved. It is a one-line fix that is much easier to get right on day one.

Whatever host you use, the rule inside n8n is the same as everywhere else. Put the key in a credential, reference the credential from nodes, and never paste a raw key into an expression or a Code node.

Where should keys never be stored?

Never store live keys in chat messages, email, shared docs, spreadsheets, CRM notes, or the text fields of a workflow step. Never commit them to a code repository, even a private one. Each of these copies the key somewhere you cannot easily audit, revoke, or find again when it is time to rotate.

Chat is the leak I check for first. Someone asks for the key, someone pastes it, the automation gets built, and the message sits in a channel history forever. If that happens, treat the key as exposed. Rotate it, store the new one properly, and move on without blame.

Spreadsheets come next. A "credentials" tab feels organized, but sheets get shared, exported, and copied without much thought. If you need a list, keep a list of which keys exist and who owns them, not the values themselves. The values belong in a password manager or the tool's own credential store.

Who should own each key?

Every key should have a named owner, a company-controlled account behind it, and a written list of the workflows that use it. Tie keys to service or shared accounts, not to a person's daily login. When the owner changes roles, the key changes hands on purpose, not by accident.

I keep a short inventory for every client stack: the service, what the key can do, which account it belongs to, where it is stored, who owns it, and which workflows depend on it. It is a small job the first time, and it saves a lot of scrambling when someone leaves or a provider forces a reset.

Ownership also means least privilege. If a tool lets you create a key that can only read contacts, and your workflow only reads contacts, use that key. Many providers let you scope access. Use the narrowest scope that still lets the workflow do its job.

This ties directly into documentation. A workflow that names its credentials clearly, and links to the inventory, is one the next person can maintain. I wrote more about that in how to name and document Zaps so someone else can fix them.

How do keys connect to webhook security?

Keys protect calls you make to other tools. Webhook secrets protect calls other tools make to you. Both need the same care. Store signing secrets in the credential store, not in a step, and verify incoming signatures so a stranger cannot trigger your workflows by guessing a URL.

Teams often lock down outgoing keys and leave incoming webhooks wide open. A webhook URL is not a secret just because it is long. If a form or app sends a signature, check it. If it does not, add a shared secret you can verify. My walkthrough on how to verify webhook signatures in a no-code automation covers the method.

The common thread is boring discipline. Secrets go in one place. References point at that place. Access is granted on purpose and written down. None of it is clever, and that is the point.

What should you do next?

Block out time for an inventory. List every service your automations touch, find where each key lives, and move any key that sits in a step, a chat, or a sheet into the proper credential store. Rotate any key that was ever pasted in chat. Then name an owner for each one.

You do not need a security team to do this well. You need a list, a password manager, and the habit of using each tool's credential store the way it was designed. That alone puts most small revenue teams ahead of where I usually find them.

If you want help auditing the keys and connections behind your automation stack, reach out. It is one of the first things I check when I take on a new GTM engineering project.