--- title: "How to Share API Keys Securely | LinkPilot Blog" description: "Practical patterns for sharing API keys with teammates and contractors without leaving the secret in chat or email history." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "SoftwareApplication", "@id": "https://uselinkpilot.com/#software", "name": "LinkPilot", "applicationCategory": "BusinessApplication", "operatingSystem": "Web", "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "url": "https://uselinkpilot.com", "offers": [ { "@type": "Offer", "name": "Free", "price": "0", "priceCurrency": "USD", "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Pro", "price": "29", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "29", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Agency", "price": "299", "priceCurrency": "USD", "priceSpecification": { "@type": "UnitPriceSpecification", "price": "299", "priceCurrency": "USD", "billingDuration": "P1M" }, "url": "https://uselinkpilot.com/pricing" }, { "@type": "Offer", "name": "Enterprise", "priceSpecification": { "@type": "PriceSpecification", "priceCurrency": "USD" }, "url": "https://uselinkpilot.com/pricing" } ] }, { "@context": "https://schema.org", "@type": "Organization", "@id": "https://uselinkpilot.com/#organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "parentOrganization": { "@type": "Organization", "@id": "https://tetracorehq.com/#organization", "name": "TetraCore", "url": "https://tetracorehq.com/" }, "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 }, "description": "LinkPilot is a secure link management platform for creating branded short links, tracking engagement, and sharing secrets with expiring, protected, self-destructing links.", "sameAs": [ "https://x.com/uselinkpilot", "https://www.linkedin.com/company/uselinkpilot", "https://facebook.com/uselinkpilot" ] }, { "@context": "https://schema.org", "@type": "WebSite", "name": "LinkPilot", "url": "https://uselinkpilot.com", "potentialAction": { "@type": "SearchAction", "target": "https://uselinkpilot.com/blog?q={search_term_string}", "query-input": "required name=search_term_string" } }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://uselinkpilot.com" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://uselinkpilot.com/blog" }, { "@type": "ListItem", "position": 3, "name": "How to Share API Keys Securely", "item": "https://uselinkpilot.com/blog/how-to-share-api-keys-securely" } ] }, { "@context": "https://schema.org", "@type": "BlogPosting", "@id": "https://uselinkpilot.com/blog/how-to-share-api-keys-securely#article", "headline": "How to Share API Keys Securely", "description": "Practical patterns for sharing API keys with teammates and contractors without leaving the secret in chat or email history.", "datePublished": "2026-05-26", "dateModified": "2026-07-14", "image": "https://uselinkpilot.com/logo-512.png", "author": { "@type": "Person", "name": "W. Miller", "worksFor": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com" } }, "publisher": { "@type": "Organization", "name": "LinkPilot", "url": "https://uselinkpilot.com", "logo": { "@type": "ImageObject", "url": "https://uselinkpilot.com/logo-512.png", "width": 512, "height": 512 } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://uselinkpilot.com/blog/how-to-share-api-keys-securely" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Is it really that bad to send an API key in Slack?", "acceptedAnswer": { "@type": "Answer", "text": "It's not the act of sending — it's the permanence. Chat history is searchable, syncs to mobile, gets exported in compliance reviews, and survives offboarding. A one-time link removes the secret from the channel after a single read." } }, { "@type": "Question", "name": "Should I just use a password manager?", "acceptedAnswer": { "@type": "Answer", "text": "Yes, for long-lived credentials. Use a manager as the system of record and a one-time link only for the hand-off. Many teams use both — the link moves the key, the vault stores it." } }, { "@type": "Question", "name": "What if the recipient needs the key again later?", "acceptedAnswer": { "@type": "Answer", "text": "Don't re-send the original — issue a new key or have them store it in a manager when they receive it. Re-sharing defeats the rotation story and muddies the audit trail." } }, { "@type": "Question", "name": "How do I get an API key into CI/CD?", "acceptedAnswer": { "@type": "Answer", "text": "Not with a link. Machines should read from your platform's secret store — GitHub Actions secrets, GitLab CI variables, AWS Secrets Manager, Vault. One-time links are for human-to-human hand-offs only." } }, { "@type": "Question", "name": "Can LinkPilot read the API key I share?", "acceptedAnswer": { "@type": "Answer", "text": "We're candid about this on the Security Architecture page: payloads are TLS-protected in transit and encrypted at rest, but we do not claim end-to-end encryption — an operator with database access could in principle read an active secret, as with any managed-database SaaS. Short expiry plus burn-after-read minimizes that window, and burned payloads are overwritten and unrecoverable." } } ] } ] --- [![LinkPilot](/link_pilot_icon.webp)LinkPilot ](/) [Features](/features)[Tools](/tools)[Blog](/blog)[Pricing](/pricing)[FAQ](/#faq) Toggle theme [Sign In](/login)[Start free](/signup) 1. [Home](/) 2. [Blog](/blog) 3. [Security](/blog/category/security) 4. How to Share API Keys Securely [Security](/blog/category/security) # How to Share API Keys Securely Practical patterns for sharing API keys with teammates and contractors without leaving the secret in chat or email history. By W. Miller · May 26, 2026 · 7 min read The shortest version: **don't paste the key into chat or email**. Send a [one-time link](/glossary#one-time-link "Glossary: one-time link") instead, and rotate any key that has already been in plaintext where it shouldn't have been. The rest of this guide is the detail: why the obvious channels fail, the exact hand-off procedure, what to do when a key leaks anyway, and the cases where a one-time link is the wrong tool. ## Why chat and email fail - **Both are searchable forever.** A key shared in 2023 is a key your next incident is sourced from. Attackers who land in a corporate chat or mailbox routinely search it for exactly the strings API keys look like — `sk_live`, `AKIA`, `ghp_`, `Bearer`. - **Both sync everywhere.** Phones, personal laptops, tablets — devices that are out of scope for your security controls and out of reach for your remote-wipe policy. - **Both get exported.** Compliance reviews, legal discovery, and workspace exports all produce copies of history. Every [export](/glossary#link-import "Glossary: export") is another place the key lives. - **Both survive offboarding.** The contractor's engagement ends; the DM thread with your Stripe key in it does not. Putting a secret into either tool means accepting that the secret lives wherever the message ends up, for as long as anything retains it. Neither system was designed to forget. ## Before you share: shrink the key The best hand-off is one where the key being handed off barely matters. Before generating anything, apply least privilege at the source: - **Scope it.** Stripe restricted keys, GitHub fine-grained personal access tokens, AWS IAM policies scoped to specific actions and resources — most serious providers let you mint a key that can do only the one thing the recipient needs. - **Prefer read-only** unless writes are genuinely required. - **Set provider-side expiry** where the platform supports it (GitHub fine-grained PATs, AWS temporary credentials via STS). Then even a leaked key has a shelf life independent of anything you do downstream. - **Name it after the recipient** (`vendor-x-readonly`) so that six months from now, revoking it is a one-look decision instead of an archaeology project. A scoped, expiring, read-only key turns a worst-case leak from an incident into an annoyance. ## The hand-off pattern 1. **Generate the key in the source system** (AWS, Stripe, your own API) with the minimum scopes, per above. 2. **Paste it into a one-time [secret link](/glossary#secret-link "Glossary: secret link")** with [burn-after-read](/glossary#burn-after-read "Glossary: burn-after-read") on and an expiry of a few minutes to a few hours — just long enough for the actual hand-off, no longer. 3. **Add a passphrase, delivered through a different channel** — link by email, passphrase by SMS or Slack DM. If either channel leaks, the attacker still has only half the puzzle. (LinkPilot hashes the passphrase in the browser with SHA-256 before it's sent; the raw passphrase never reaches the server's database or logs, and attempts are rate-limited to 5 per IP per minute.) 4. **Send the link.** 5. **Confirm out-of-band that the recipient retrieved it**, and check the audit timeline: one view, expected time, expected location. That's your receipt. If the link goes unread past the expiry, revoke it and resend — don't extend, and don't reuse. ## Example: passing a Stripe restricted key ```bash # generate a restricted key with the minimum needed scopes stripe api_keys create \ --restricted \ --display-name "vendor-x-readonly" # pipe the resulting key into a LinkPilot secret curl -X POST https://api.uselinkpilot.com/v1/secrets \ -H "Authorization: Bearer $LP_KEY" \ -d 'payload=sk_restricted_…' \ -d 'expires_in=3600' \ -d 'burn_after_read=true' ``` What the recipient experiences: opening the link shows a reveal page — not the key. Link unfurlers and email scanners that prefetch the URL get metadata only, because a view is recorded solely on the explicit reveal action, never on the `GET`. When the recipient clicks reveal (and enters the passphrase, if set), they see the key exactly once. After that, the stored payload is overwritten and the link returns [HTTP](/glossary#http "Glossary: http") 410. Even if the email forwards itself around the company, only the first viewer could ever have read it — and the [audit trail](/glossary#link-history "Glossary: audit trail") shows you who that was. ## Which channel for which hand-off Situation Recommended method Notes Teammate, same room or on a call One-time link, 5–15 min expiry Passphrase optional — you can confirm receipt live Remote teammate One-time link + passphrase via second channel 1-hour expiry default Contractor or agency Scoped key + one-time link + passphrase Name the key after them; calendar the revocation for engagement end Customer receiving their own key One-time link from your app or support flow 24-hour expiry; instruct them to store it immediately CI/CD pipeline or service Platform secret store (Actions secrets, Vault, ASM) Never a link — machines don't do hand-offs Whole team, ongoing access Password manager vault This is storage and access control, not a hand-off ## If a key leaks anyway: the rotation runbook Treat any key that touched a chat message, email body, screenshot, git commit, or public paste as burned. In order: 1. **Issue the replacement key first**, if the provider allows two active keys — this avoids downtime for legitimate consumers. 2. **Revoke the leaked key at the provider.** This is the only step that actually ends the exposure; deleting the Slack message does not. 3. **Hand off the new key properly** — one-time link, passphrase, short expiry, per the pattern above. 4. **Check the provider's usage logs** for the leaked key between exposure and revocation. Unexpected calls mean this is now an incident, not a cleanup. 5. **Fix the source of the paste** — add the secret to your `.gitignore`d env tooling, enable secret-scanning in your repo host, or update the runbook that told someone to DM it. The whole loop should take minutes. If rotating a key is scary enough that people avoid it, that fragility is the real vulnerability — fix that first. ## What to avoid - **Re-sending the same secret.** Rotate instead. Re-sending erases the "exactly one exposure" audit story that made the one-time link worth using. - **Long expiry windows.** Default to short. Most hand-offs complete in minutes; an 8-hour window is just a longer leak. - **Skipping the passphrase.** It costs almost nothing and defends against accidental URL leaks — forwarded emails, screen shares, shoulder surfing on a shared screen. - **Screenshots of keys.** They land in camera rolls, cloud photo sync, and image search. A screenshot is chat-paste permanence with worse searchability for _you_ and fine searchability for OCR. - **Using the link tool as storage.** The link is the courier, not the vault. The recipient should store the key in a password manager or env tooling the moment they receive it. ## When a one-time link is the wrong tool Honesty section — this pattern has edges: - **Machine-to-machine credentials** belong in a secrets manager or the platform's native store, injected at deploy or runtime. A human clicking a link is not a deployment step. - **Long-lived shared credentials** belong in a password manager with real access control and revocation per person. - **High-frequency rotation** (keys that change hourly) should be automated end to end; humans and links shouldn't be in that loop at all. - **Secrets you cannot afford to have any third party store, even encrypted at rest** — use an end-to-end encrypted tool or move the hand-off offline. LinkPilot is explicit that it does not claim E2EE; see the [Security Architecture](/security-architecture) page for exactly what is and isn't protected. For the common case — one human handing one credential to another human, once — the one-time link with a passphrase and a short expiry is the strongest simple pattern available. ## Related reading - [Why URLs leak sensitive information](/blog/why-urls-leak-sensitive-information) - [Secure password sharing](/secure-password-sharing) - [LinkPilot Security Architecture](/security-architecture) - [How to send a password securely](/blog/how-to-send-a-password-securely) - [URL shortener API comparison](/blog/url-shortener-api-comparison) ## Frequently asked questions ### Is it really that bad to send an API key in Slack? ### Should I just use a password manager? ### What if the recipient needs the key again later? ### How do I get an API key into CI/CD? ### Can LinkPilot read the API key I share? ## Run smarter links with LinkPilot Tracking, UTMs, QR codes, AI insights, and white-label reporting — in one workspace. Free to start. [Create your free account](/signup) ## Read next [ Security ### OneTimeSecret vs Privnote vs Password Pusher: Which Should You Use? A three-way comparison of the most popular secret-sharing tools — encryption, expiry, revocation, self-hosting, and where each one genuinely wins. ](/blog/onetimesecret-vs-privnote-vs-password-pusher)[ Security ### Is Privnote Safe? An Honest Security Assessment (2026) Privnote's core mechanism works, but clone-site phishing, closed source code, and zero auditability are real risks. Here's a fair assessment and safer setups. ](/blog/is-privnote-safe)[ Security ### How to Send a Password Securely (Without Leaving It in Chat Forever) The safest way to send a password is a one-time encrypted link that self-destructs after viewing. Here's every method ranked, with the trade-offs spelled out. ](/blog/how-to-send-a-password-securely) On this page - [Why chat and email fail](#why-chat-and-email-fail) - [Before you share: shrink the key](#before-you-share-shrink-the-key) - [The hand-off pattern](#the-hand-off-pattern) - [Example: passing a Stripe restricted key](#example-passing-a-stripe-restricted-key) - [Which channel for which hand-off](#which-channel-for-which-hand-off) - [If a key leaks anyway: the rotation runbook](#if-a-key-leaks-anyway-the-rotation-runbook) - [What to avoid](#what-to-avoid) - [When a one-time link is the wrong tool](#when-a-one-time-link-is-the-wrong-tool) - [Related reading](#related-reading) ![LinkPilot](/assets/link_pilot_icon-Bslvq5xV.webp)LinkPilot [About](/about)[Features](/features)[Pricing](/pricing)[For Agencies](/url-shortener-for-agencies)[Tools](/tools)[Blog](/blog)[Glossary](/glossary)[Compare](/compare)[Privacy](/privacy)[Security](/security-architecture)[Transparency](/transparency)[Terms](/terms)[GDPR](/gdpr) [](https://x.com/uselinkpilot)[](https://www.linkedin.com/company/uselinkpilot)[](https://facebook.com/uselinkpilot) © 2026 TetraCore. All rights reserved. · LinkPilot is [a TetraCore product](https://tetracorehq.com/)