What Is an API Key? A Plain-English Explanation
API keys explained without jargon: how they differ from an OAuth login, where to paste one safely in Zapier/Make/n8n, and what to do if one leaks.
Quick answer
An API key is a long string of random characters that acts like a password for software instead of a person — it proves to a service that whatever is calling it (your no-code workflow, an app, a script) is allowed to use that service's API. You paste it once into a connector's settings, and every request your automation makes afterward carries that key along to prove it's authorized.
How it works, in practice
- You create an account with a service (say, a weather API, a CRM, an email provider)
- Somewhere in that service's dashboard — usually under "Developer," "API," or "Integrations" settings — you generate a key
- You paste that key into the no-code tool's connector (a Zapier "Connect" step, a Make module, an n8n credential)
- From then on, every request the automation sends includes the key, and the service checks it before doing anything
If the key is missing, wrong, or has been revoked, the service rejects the request — that's the 401 Unauthorized error you'll see in Zapier, Make, or n8n when a key stops working (the same status code shows up when a webhook's own authorization fails, for the same underlying reason: the request arrived without valid proof it's allowed).
API key vs. OAuth login — the distinction that actually matters
Both let a no-code tool act on your behalf, but they work differently under the hood:
| API key | OAuth (the "Sign in with Google/Slack/etc." flow) | |
|---|---|---|
| What it proves | The calling application is authorized | You, specifically, authorized this exact access |
| Expiration | Usually none — valid until you manually revoke it | Automatically expires, typically minutes to hours, refreshed behind the scenes |
| Scope | Often all-or-nothing for the account | Granular — can be limited to "read messages" without "send as you" |
| How you connect it | Copy-paste a string into a field | Click "Connect," log in, approve permissions in a popup |
In practice: when a no-code tool's connector says "Connect Account" and opens a login popup, that's OAuth. When it shows a plain text field labeled "API Key" or "Secret Key," that's a key. Many services — Stripe and OpenAI among them — only offer API keys, no OAuth option, because they're built for server-to-server use rather than "a person is present to click approve."
Why an API key without an expiration date is a real risk
An API key that never expires on its own means anyone who gets a copy of it — through a leaked screenshot, a committed config file, a shared spreadsheet — has standing access until you notice and manually revoke it. There's no automatic cutoff working in your favor the way there is with an OAuth token. That's the whole reason "don't paste API keys where they can be seen" isn't paranoia; it's the entire security model resting on the key staying secret.
Where API keys go wrong in no-code workflows specifically
Pasted into a public or shared Google Sheet. A common no-code pattern is storing config values (API keys included) in a spreadsheet a workflow reads from. If that sheet's sharing settings are "anyone with the link," the key is effectively public.
Left in a workflow exported as a template or shared for troubleshooting. Exporting a Zap, Make scenario, or n8n workflow JSON to ask for help in a forum can carry the key along inside a node's stored credentials or a hardcoded value — always check before pasting workflow exports publicly.
Never rotated after an employee or contractor leaves. Unlike an OAuth connection tied to one person's login (which breaks the moment that person's account access is removed), a shared API key keeps working for whoever still has a copy of it, indefinitely, until someone manually regenerates it.
Put directly in a URL instead of a header. Some older or simpler APIs accept the key as a URL parameter (?api_key=abc123). URLs get logged by proxies, browser history, and analytics tools by default — a key that only ever needs to travel in a request header shouldn't also be a query parameter if the service supports both.
What to do if a key leaks
Revoke (or "regenerate") it immediately in the issuing service's dashboard — this invalidates the old key instantly and issues a new one. Then update every place that used the old key (every Zap, Make scenario, or n8n credential referencing it) before anything tries to run with the now-dead key and fails. There's no way to "un-leak" a key once it's out; revoking is the only real fix, not rotating it "when convenient."
FAQ
Is an API key the same thing as a password?
Functionally similar — both prove identity to unlock access — but a password identifies a person logging into an interface, while an API key identifies software making automated requests. Most services also let you generate multiple API keys per account (one per integration), so you can revoke one without breaking every other connection, which isn't how a single account password works.
Why does Zapier/Make/n8n sometimes ask for an API key and sometimes open a login popup for the same category of service?
It depends entirely on what the underlying service supports, not on the no-code tool. Services built primarily for developers (Stripe, OpenAI, most analytics platforms) tend to offer only API keys. Consumer-facing platforms with their own login system (Google, Slack, Salesforce) usually support OAuth, which no-code tools prefer to offer when available since it doesn't require the user to hunt through developer settings. This connector-support question is also one of the practical differences worth checking before committing to a platform — see the n8n vs Zapier vs Make comparison for how each handles third-party connections generally.
Can I limit what an API key is allowed to do?
Depends on the service — some let you scope a key to read-only access or to a specific project/resource when you generate it, others issue one key with full account access and no way to narrow it. Check the issuing service's key-generation screen for scope options before assuming a key is as narrow as you'd like.
Is it safe to store an API key directly inside a Zapier/Make/n8n connection?
Yes — that's what those connector fields are built for, and reputable platforms store the key encrypted rather than in plain text. The risk isn't storing it in the connector; it's copying it elsewhere afterward (a spreadsheet, a shared doc, a public repo) where it isn't protected the same way.
Last fact-checked: August 18, 2026.