Security

How to Collect API Keys From Clients Securely

Collect a client's API keys and tokens through an end-to-end encrypted request, one structured intake for every key the automation needs, not a Slack DM or a spreadsheet. Here's the workflow and how to keep the keys straight across projects.

The safe way to collect a client's API keys is an end-to-end encrypted request they open without an account, with a labelled field for every key the automation needs. Each key is encrypted in the client's browser before it's sent, so it never lands in a Slack DM, an email, or a spreadsheet. Where a service supports OAuth, use that instead of collecting a raw key.

Why Slack and spreadsheets are the wrong place for a key

An API key is a live credential. An LLM key is a metered charge on the client's account; a CRM or database token is their customer records. Pasted into Slack it's retained on Slack's servers, readable by workspace admins on paid plans and by connected apps, and searchable in history. In a shared spreadsheet it sits in plaintext on a drive anyone with the link can reach. Neither can be revoked or expired, and neither tells you who saw the key.

Prefer OAuth, then collect the rest

Some services let you connect through OAuth, which grants scoped, revocable access without the client ever handing over a raw key. Use it where it exists. But plenty of integrations, older APIs, database credentials, service-account keys, still require the raw value, and those are what you collect, encrypted, rather than over chat.

How the channels compare

Method	Encrypted so only you can read it?	Lives in history you don't control?	Structured across many keys?
Slack / email	No	Yes	No
Shared spreadsheet	No	Yes	Partly
One-time secret link	Yes	No	No (one secret at a time)
Encrypted credential request	Yes	No	Yes

How to collect API keys cleanly

List every key the build needs, by service, so nothing is chased later: LLM, CRM, email, webhooks, database.
Send one structured request, a labelled field per key, not a thread of "can you also send…".
Tell a non-technical client where to find each key, with a one-line hint per field.
Encrypt on the client's device, so the raw keys never sit in a message.
Keep the list for offboarding, so you know exactly which keys to rotate or revoke when the project ends.

Where doconvoy fits

A single doconvoy request collects the whole set of keys for a project. The client opens a page in your name, pastes each key into its labelled field, and every one is encrypted in their browser before it reaches you, so doconvoy never sees a readable key. See it applied to the field in collecting credentials for AI automation agencies.

Send one encrypted request for every key an automation needs, no account, no Slack DMs.

Collect client API keys securely

Common questions

What's the safest way to collect API keys from a client?

Through an end-to-end encrypted request the client opens without an account, with a labelled field for each key the build needs. The key is encrypted in their browser before it's sent, so it never sits in a Slack message, email, or spreadsheet.

Why not collect API keys in Slack or a shared doc?

A key pasted into Slack or a Google Doc stays there in plaintext, readable by anyone with access to the thread, retained on the platform's servers, and reachable by connected apps. An API key is a live credential to the client's account, so that's the wrong place for it.

Should I use OAuth instead of collecting a raw API key?

Where the service supports it, yes, OAuth gives scoped, revocable access without handing over a raw key. Many services and legacy integrations still only offer a raw API key, and those are the ones worth collecting through an encrypted request.