What your key can actually do
Most people think of an API key as "a password for this one task." It is not. A typical CRM API key carries the full permissions of the account that created it. Read everything. Often write everything. Sometimes delete. There is no scope called "just this one export" in most CRMs' key systems. When you paste the key, you are not lending a tool one ability. You are lending it your account.
The question nobody asks: where does the key sleep?
The safety of the whole arrangement comes down to one boring question: after the tool uses your key, where is it? The honest range of answers, worst to best:
- Stored in plain text in a database, forever, because storing it was easier than not. One breach of that tool becomes a breach of every customer's CRM.
- Stored encrypted. Much better, and still means the key exists somewhere to steal, leak or subpoena, protected only by that vendor's discipline.
- Used in memory and discarded. The key arrives, authenticates your run, and is gone when the run ends. There is nothing to breach later, because there is nothing later.
How we handle it, and the honest second half
Our default is the last one, by design. Your key lives in the request's memory inside the serverless function handling your run, and nowhere else. There is no credential database to breach because there is no credential database. And here is the honest second half: some features genuinely need a stored credential. A scheduled run cannot happen at 6am with a key that evaporated at 5pm. So when we ship scheduling, saved connections will exist as a clear opt-in: encrypted, revocable, and labelled. Storage as a choice you make. Never a default you discover.
The safest place to keep a secret is nowhere. Every other answer is a trade-off that should be yours to accept, not the vendor's to assume.
Your pre-paste checklist
- Does the tool say what happens to the key? Silence on this question is an answer.
- Is the access read-only where it could be? A tool that only exports should not hold write scopes. Create the narrowest key your CRM allows.
- Can you rotate afterwards? For one-off use of an unfamiliar tool, rotating the key after the run costs a minute and removes the risk completely.
- Prefer OAuth when offered. OAuth grants are scoped and revocable from your CRM's side, which beats any pasted key. Good tools offer it wherever the platform supports it.
The industry norm is worse than you think
None of this would be worth an article if in-memory handling were normal. It is not. Storing credentials by default, silently, is the industry's overwhelming habit, because storage enables convenient features and nobody reads privacy policies. Ask the question anyway. The tools with a good answer will have it ready.
Frequently asked questions
Is it safe to paste my CRM API key into a third-party tool?
Only if you know what the tool does with it. The safe pattern is in-memory use, where the key authenticates your run and is never written to storage. Tools that store keys, especially by default, concentrate breach risk.
What is the safest way for a tool to handle API keys?
Use the key in memory for the duration of the request and discard it. If a feature genuinely requires stored credentials, such as scheduled runs, storage should be explicit opt-in, encrypted and revocable.
Should I rotate my API key after using an export tool?
For unfamiliar tools, yes: rotating after a one-off run takes a minute and eliminates any residual risk. For tools you trust and use regularly, periodic rotation is still good hygiene.
Why is OAuth better than pasting an API key?
OAuth grants are scoped to specific permissions and revocable from the platform's own settings, so you can cut off a tool without changing credentials everywhere. A pasted full-access key has neither property.