An API key pasted into a chat thread, support ticket, or email is often already outside your security boundary. The question is not only how to send API keys, but how to ensure the key is exposed to the fewest people, systems, logs, and retention policies possible.
For engineering teams, the right method depends on what is happening next. An application authenticating to an API has different requirements from a customer providing a credential to your team. Treating both cases as simple text transfer is how credentials end up in browser histories, CI logs, ticket exports, and inbox archives.
First, separate API use from API-key sharing
When software needs to present an API key to a service, use the authentication mechanism specified by that service. In most cases, that means sending the credential over HTTPS in an HTTP request header. Common patterns include an `Authorization: Bearer ` header or a vendor-specific header such as `X-API-Key: `.
Headers are not inherently secret. They can still be captured by application logs, proxies, observability tools, and debugging middleware. Their advantage is operational: teams can consistently identify, redact, and restrict sensitive headers. Query parameters are materially worse because URLs are frequently retained in access logs, browser history, analytics tooling, caches, referrer headers, and error reports.
A request body may be acceptable when a provider explicitly requires it, but it should not become the default. Never send a key in a URL query string, and do not put long-lived production credentials in client-side JavaScript, mobile apps, public repositories, or configuration files committed to source control.
When a person or third party must provide a key to your organization, do not ask them to paste it into email, Slack, a project-management system, or a web form that stores submissions in a general database. Use a purpose-built secure collection workflow instead.
How to send API keys to an application safely
Start with transport security. Every request carrying a credential must use HTTPS with current TLS configuration and certificate validation enabled. Reject plaintext HTTP. This sounds elementary, but internal services, local proxies, legacy integrations, and misconfigured load balancers still create exceptions that turn a sound policy into an exposed credential path.
Then select the narrowest viable credential. A scoped API key with a short expiration is safer than an account-wide key that never expires. If the provider supports OAuth access tokens, workload identity, signed requests, or short-lived credentials issued through a cloud identity platform, those options often reduce the blast radius further. API keys remain common because they are easy to deploy, not because they are always the strongest design.
Store the credential outside application code. Production services should retrieve it at runtime from a secrets manager, protected environment injection mechanism, or dedicated vault. Local development can use an ignored environment file, provided the file is excluded from version control and developers understand that shell history, process inspection, and copied terminal output can still expose values.
A typical server-to-server request may look like this:
“`bash curl –request GET –url “https://api.example.com/v1/projects” –header “Authorization: Bearer $API_KEY” “`
The command is only safe if `$API_KEY` comes from a protected environment and the shell command is not recorded or shared. Avoid hardcoding the literal key into scripts, documentation, CI configuration, or screenshots. In CI/CD systems, use protected secret variables and ensure masking is enabled. Masking helps, but it is not a substitute for access controls or rotation.
Redact before logging
The most common failure is not interception in transit. It is a key copied into logs after an application exception, a failed request trace, or a support bundle.
Configure application, gateway, and observability tooling to redact authorization headers and known secret fields before events are written. Ensure error handlers do not serialize complete request objects. Review third-party SDKs as well: verbose debug modes can log headers, request payloads, and retry metadata that your application logger never sees.
Test this deliberately. Send a non-production canary credential through normal request paths, trigger an error, and search log stores, traces, alerts, and data exports. If the value appears anywhere it does not belong, fix the collection point before relying on the integration.
How to receive API keys from clients and partners
Credential collection introduces a different threat model. The sender may be nontechnical, may not have access to your password manager, and may be responding under time pressure. A secure process has to be easier than email or people will route around it.
Use a secure submission link that encrypts the credential and limits who can access it. The link should be delivered through a channel appropriate to your relationship, but the secret itself should be entered only into the secure collection interface. For higher-risk credentials, use burn-on-view controls so the submitted value is available once, then removed. For recurring integrations, persistent storage in an access-controlled vault may be appropriate, but only when operational need justifies retention.
Securitae provides secure links for collecting API keys from clients and third parties without requiring them to create an account. Its encrypted collection workflow can synchronize submitted secrets to controlled destinations such as 1Password, Slack, or dedicated vaults. Bridge mode is useful where local retention is unacceptable because it deletes local data after a successful synchronization.
The sender should know three things before submitting a credential: what access the key grants, why you need it, and how long you intend to retain it. This is not merely good communication. It helps the sender issue the correct scope and gives your team a defensible basis for rejecting overly broad credentials.
Verify ownership and intended scope
Receiving a key securely does not mean it is safe to use without review. Confirm the client or partner is authorized to provide it, particularly when the key belongs to a shared cloud account, payment platform, production analytics tenant, or regulated environment.
Check the scope before activation. A key that can read production data, create users, delete resources, and manage billing is rarely necessary for a single integration. Request separate development and production keys where supported. Apply IP restrictions, service restrictions, allowed origins, or resource-level permissions when the provider offers them.
If a provider cannot scope keys sufficiently, compensate with an internal boundary. Put the credential behind a narrowly defined integration service rather than distributing it to multiple applications, scripts, or employees.
Avoid the shortcuts that create incidents
Teams often reach for encrypted email, password-protected ZIP files, direct messages, or a password manager item shared to a large group. Each may be better than plaintext email in a narrow scenario, but each has limitations. Encrypted email depends on correct key management and recipient behavior. ZIP passwords are commonly sent through the same channel as the archive. Broad password-manager sharing makes access review and revocation harder.
A secure sharing process should support least privilege, expiration, access auditing, and revocation. It should also remove the secret from informal systems where retention is uncontrolled. The correct control is proportional to the value and scope of the credential, but production keys should receive production-grade handling.
Do not confuse encoding with encryption. Base64, URL encoding, hexadecimal formatting, and client-side obfuscation do not protect API keys. Nor does placing a key behind a feature flag or hiding it in a frontend build artifact. If a browser or mobile client can retrieve the secret, a determined user can retrieve it too.
Build rotation into the handoff
Every API-key transfer should have an expiration and replacement plan. Record the key owner, system, environment, intended permissions, storage location, and rotation date in your internal inventory. Avoid storing the value itself in tickets or inventory records. The record should point to the vault entry or secret reference, not duplicate the credential.
Rotate immediately when a key is sent through an unapproved channel, appears in logs, is committed to source control, is accessible to a departing employee, or is exposed by a vendor incident. For planned rotation, create the replacement key first, deploy it, verify service health, then revoke the prior key. This overlap prevents avoidable outages.
Automated secret scanning should be part of the safety net. Scan repositories, CI output where feasible, infrastructure definitions, collaboration tools, and public package artifacts. Detection is not a reason to tolerate weak sharing habits, but it limits the duration of a mistake.
The safest API key is one that is short-lived, narrowly scoped, encrypted in transit and at rest, absent from logs, and easy to revoke. Make that path the easiest one for developers and clients, and insecure workarounds lose their appeal.