Every developer who works with external clients has had this exchange:

Me: "Could you send me the FTP credentials for your old hosting?" Client: attaches a screenshot of the credentials in their reply email

The client isn't malicious. They're not even unusually careless. They're doing what their email taught them to do — replying with the requested information. The problem is that the request itself was framed in a channel that defaults to plaintext, persistent storage. Once you asked over email, the client's mental model of "where this conversation lives" was already set.

Asking the client for the credential differently is the lever. This article covers how to request sensitive information from clients without using email, with specific patterns for the most common scenarios — agency onboardings, vendor relationships, customer support, and one-off consulting engagements.

Why "email then we'll move it later" doesn't work

A common pattern: ask over email, then say "actually, can you send the password through this secure tool instead?" Two failure modes:

The client sends it anyway. They're busy, they read your first message and reply to it, they don't read your follow-up before answering. The credential is now in their inbox and yours.
The client gets confused and stops responding. Your "secure tool" looks suspicious to them. They think it's a phishing attempt and ghost you.

The credential has already crossed the wire by the time you sent the second email. The damage is done.

The fix: ask through the secure channel from the first message. The client never had email as a perceived option.

The "request link" pattern

The right shape for client credential collection is a link the client clicks, not a message they reply to.

Specifically:

You generate a "request link" in a secure share tool. The link has a form labeled with the credential you need ("Please paste your AWS access key here").
You send the link via email or chat.
The client clicks, sees a form, fills it in. The form encrypts client-side before submission.
Only your browser holds the decryption key. The relay service can't read the data.
You open the response, copy the credential into your password manager. The link self-destructs.

The client's email inbox never contains the credential. Your inbox never contains the credential. The credential is in your password manager and the client's password manager (or wherever they keep it), not in any chat history.

This pattern is sometimes called "Secure Receive" or "credential request" depending on the tool. It's the inverse of the more common "send a secret" flow, and it's underused.

A real onboarding scenario

A digital agency onboards a new client. They need:

WordPress admin credentials
WP-CLI SSH access (separate from admin)
AWS S3 bucket credentials for the assets bucket
Stripe restricted API key for the payment flow
Google Analytics property access
Mailchimp API key

In the bad version, this is a back-and-forth email thread. The client sends each credential as a reply. Six credentials, six emails, six persistent records in both inboxes.

In the good version, the agency sends one message:

Hi, welcome aboard. To get your project moving, I've created a secure intake form for the credentials we'll need. The form is end-to-end encrypted — only our browser can decrypt what you send.

Please fill in: [secure-link]

Each field is optional; if you don't have something handy, you can leave it blank and we'll follow up. The link expires in 7 days.

The client clicks once, fills in what they have, submits. The agency receives an encrypted blob they decrypt locally and import into their password manager. The client's email never contained any of those credentials.

The trust-building part

Clients are reasonably skeptical of "click this secure link." It looks like phishing. The fix is to lead with what makes it credible:

Send from a known channel. The first time you mention the secure link, send the message from your established work email address that the client has been corresponding with.
Explain in one line what the tool is. Don't say "click the secure link." Say "I'm using a self-destructing share tool — the link expires once you submit, and even the tool's operator can't read what you send."
Provide a fallback if they're uncomfortable. Some clients will refuse to use a tool they've never heard of. For those, say "if you'd prefer, we can do this over a phone call — you read me the credentials, I type them into our password manager."
Use a recognizable tool. Tools with established trust signals (HTTPS, clear branding, public security documentation) get more clicks than something that looks like a one-off form.

The first interaction is the trust-establishing one. After the first successful exchange, clients usually accept the tool as part of "how this agency works."

What about non-technical clients?

The receive-link pattern works specifically because non-technical clients don't need to install anything. They click a link, see a form, type into the form, click submit. That's a workflow they already know from every web form they've ever filled in.

Where it breaks: clients who are deeply unfamiliar with the web. For them, the answer is voice — "I'll call you, you read me the credentials, I'll type them in." The credential lives only in the call (which isn't recorded) and your password manager. The client's experience is "I told someone over the phone," which they understand.

Adjacent scenarios

The same pattern fits several other workflows:

Customer support escalations. "Send me your account password so I can investigate" is the wrong message. "Click this link, type your password, only my browser can decrypt it" is the right one. Or better: don't ask for the password at all; use a customer-impersonation feature in your support tool.

Vendor credential intake. When you onboard a new SaaS vendor that requires you to provide credentials (CI/CD tokens, webhook secrets, etc.), some vendors send a request link. Most still ask over email. You can be the one who insists on a secure channel.

Contractor reverse-onboarding. When a contractor leaves and needs to hand over credentials they own (their CI tokens, vendor accounts they registered), a request-link pattern is the right shape — one form, all the credentials at once, self-destructing.

Where SnapSend fits in

The "Secure Receive" feature in SnapSend was built specifically for this pattern. You generate a request link with custom field labels (e.g., "WordPress admin password," "WP-CLI SSH key," "Stripe restricted key"). You send the link to the client. The client opens it, fills in what they have, hits submit. Their browser encrypts before transmission using the public key embedded in the URL fragment. Only your browser, with the matching private key from your original session, can decrypt.

The relay server stores ciphertext only. The link self-destructs after first decryption or at the expiry you set. The client never needed an account; you never needed to ask twice.

For agency onboardings specifically, SnapSend lets you save request templates — the same set of fields you collect from every new client — so creating the link for a new engagement is a one-click action.

Stop asking by email

The next client relationship you start, send the credential request as a self-destructing receive link instead of "please reply with...". The client experience improves (one form vs. six emails). Your liability drops (zero credentials in either inbox). Your retention discipline gets better (every credential ends up in your password manager, not in your search results).

Try SnapSend free at snapsend.site — no account needed.