How should API keys be stored?

API keys should be treated as sensitive credentials. A business should keep them out of source code, public repositories, browser-delivered content, general documents, and ordinary messages. The safer pattern is to hold each key in an approved secrets-management system, let only the necessary workload retrieve it, restrict what the key can do, and maintain a tested process for monitoring, rotation, and revocation.

Start with a managed secret store

A managed secret store is designed to keep sensitive values encrypted, control who or what may retrieve them, and record access activity. The application requests the key when it needs it instead of carrying the value inside its source code or a shared configuration document. This reduces the number of places where a key can be copied, forgotten, or exposed during routine development and support work.

Choose a secrets-management method that fits the application's hosting environment and operating model. Evaluate encryption, access controls, audit records, version handling, recovery, and rotation support. A password manager may be appropriate for a person who occasionally needs a key, while an application workload generally needs a controlled machine-to-machine retrieval method. The exact implementation should follow the current documentation for the issuing service and the selected secret store.

Keep keys out of exposed locations

Source and project history

Do not place a live key in application source, examples, test fixtures, repository history, issue threads, or build output. Ignoring a file later does not remove a secret that was already committed or copied elsewhere.

Browsers and mobile applications

A secret embedded in client-delivered content can be inspected by a user or automated tool. Keep privileged calls on a controlled server unless the provider explicitly offers a public, restricted credential for that client-side use.

Messages, logs, and support records

Avoid pasting keys into email, chat, screenshots, tickets, analytics events, command history, or general forms. Redact values in logs and use the provider's approved secure channel when support needs sensitive information.

Give each key the smallest useful scope

Create separate credentials for separate applications, services, environments, and important workflows when the provider supports that structure. A development key should not automatically unlock production activity, and one vendor connection should not need the credentials assigned to another. Clear ownership makes it easier to identify a key, review its use, and replace it without disrupting unrelated systems.

Grant only the operations and resources required for the intended workload. Restrict network origin, application, domain, account, or other context only where the issuing provider documents that control and the restriction matches the real traffic path. Review access to the secret store as well as the permissions attached to the API key itself; protecting one layer does not correct overly broad access at the other.

Build a manageable key lifecycle

Keep an inventory. Record the key's purpose, owner, issuing service, environment, allowed workload, creation date, and approved replacement process without recording the secret value itself.
Prefer short-lived access where available. Workload identity or temporary credentials can reduce dependence on long-lived keys, but availability and setup differ among providers.
Plan rotation before an incident. Confirm how a new key is introduced, tested, activated, and rolled back before the old key is revoked. Avoid adopting one universal schedule without considering provider guidance and operational risk.
Remove unused credentials. Retire keys when an application, employee, vendor workflow, or environment no longer needs them, after checking for legitimate dependencies.
Review access records. Use available audit and usage signals to look for unexpected retrieval, source, volume, timing, or operation patterns.

Respond quickly to a suspected exposure

Treat a key placed in a repository, public page, message, screenshot, or unsecured file as potentially exposed. Removing the visible copy is not enough because another copy may exist in history, caches, logs, downloads, or notifications. Use the issuing provider's documented process to revoke or rotate the affected credential, then update the authorized workload through the approved secret store.

Preserve useful non-secret details such as timestamps, repository or system name, affected service, alert source, key identifier, and the actions taken. Review provider activity records for unexpected use and involve the responsible security, application, hosting, and service-provider contacts. Do not paste the key into a general incident ticket to prove that it exists. GitHub's current secret-scanning guidance likewise advises rotating an exposed credential immediately rather than assuming that removing it from history makes the credential safe.

Separate practical guidance from a security guarantee

Secret storage is one part of a broader application-security program. A well-managed key may still be misused through an overprivileged workload, vulnerable application, compromised administrator, unsafe third-party tool, or unreviewed integration. Controls should be tested against the actual architecture, and incidents should be evaluated by qualified personnel using the issuing provider's current documentation.

This page provides general operational guidance. It does not certify a system, determine compliance, promise that a control will prevent an incident, or confirm that a particular payment platform supports a specific storage or identity feature.

Continue your security review

Secure staff access

Use the guide to securing a virtual terminal to review individual accounts, authentication, managed devices, and response steps.

Protect public payment paths

Review how a website can reduce card testing attacks with layered endpoint controls, monitoring, and incident preparation.

Map adjacent risks

Explore the fraud prevention and security FAQ hub for related account, device, transaction, and response topics.

Audit one key from creation through retirement

Choose one active API key and identify its owner, purpose, storage location, permitted workload, scope, retrieval path, monitoring signals, rotation method, and revocation contact. Correct any unclear ownership or unnecessary access through the responsible provider and application team.

When contacting Payments Max about a payment workflow, describe the business need, systems involved, and desired outcome without submitting API keys, passwords, cardholder data, bank credentials, complete account numbers, or one-time codes through a general inquiry form.

To learn more about how TSYS can help improve the way your organization accepts payments, markets to new customers, or manages its HR responsibilities, get in touch by calling 585-981-8463 to get started.