How to protect API keys in identity integrations: storage, rotation, and logs.

Em KYC processesProtecting API keys means treating these credentials as secrets capable of opening or blocking access to an identity integration. A good strategy for API security It removes keys from the code and the client, limits permissions, controls storage, automates rotation, and logs enough events to investigate anomalies. The goal is not to hide a string of characters forever. It's to reduce the chance of a leak turning into unauthorized access, fraud, or operational disruption.

This changes how integration is designed. An API key should not circulate between developers, environments, and systems as if it were a shared team password. The wider the reach of the credential, the greater the impact of an error. In a API integrationProtection needs to accompany the entire lifecycle of the key, from creation to revocation.

Summary

• API keys should be extracted from source code, browsers, and client applications whenever possible.
• Environmental variables help, but secure vaults offer more adequate controls as the operation grows.
• Less privilege reduces the potential damage if a credential is compromised.
• Rotation, revocation, logs, and alerts need to function as an ongoing process, not as an improvised response to incidents.

API security begins with the key lifecycle.

The right question isn't just "where to store the API key?". It's "who can use it, for what purpose, for how long, and how do I detect abnormal use?". In an operation that involves identity validationHowever, overly broad credentials can allow for unauthorized access, generate unexpected costs, or interrupt a legitimate journey when it needs to be blocked urgently.

I have been advocating for a combination that I consider more mature: increasing security without turning protection into unnecessary friction. ZapSign's recent experience with validation mechanisms supported by telephony infrastructure has reinforced this view for me. Better governance doesn't have to mean a worse journey.

1. Remove API keys from the code and the client.

The simplest mistake is also one of the most dangerous: putting the key directly into the code, committing, and forgetting that it was recorded in the repository's history. According to the... GSI guidelinesAPI keys should not be embedded in the code or source tree and can be maintained in environment variables, external files, or key management services.

The same reasoning applies to the front-end, JavaScript delivered to the browser, and applications where the secret can be extracted. If the end user receives the key, it ceases to be truly secret. The backend should mediate the call or work with temporary and restricted mechanisms when the architecture allows. This is especially relevant when the integration helps to combat [vulnerabilities/criticism]. digital fraud.

What to do when a key leaks?

A leak in a repository should be treated as a compromise, not simply an organizational problem. Deleting the line of code does not invalidate credentials or remove existing copies.

1. Create a new credential with the smallest possible set of permissions.
2. Update the services that depend on the key and validate the calls.
3. Revoke the exposed credential once the transition is secure.
4. Review logs from the likely time of exposure and look for patterns outside of expected behavior.
5. Report the incident and correct the process that allowed the leak.

2. Store secrets according to the risk of the operation.

Environment variables are better than secrets within the code, but they don't solve all scenarios. As the number of services, environments, and people grows, a vault of secrets This provides a clearer separation between application and credential, as well as facilitating access control, auditing, and rotation. The point is to prevent production, testing, and development from sharing the same key for convenience.

It's also worth separating keys by service. An application that only queries a specific resource shouldn't receive write permission or access to endpoints it never uses. This design connects to the logic of... Open GatewayIntegrations gain value when security and context are built into the architecture, not added later as a patch.

3. Less privilege prevents a key from becoming a free pass.

A compromised key should not compromise the entire operation. Whenever the provider allows, limit scopes, resources, environments, origins, IP addresses, call volume, and expiration dates. Use different credentials for each application and environment. OWASP also warns about this in its [references/documents/etc.]. recommendations for REST APIsAPI keys should not be the sole protection mechanism for sensitive and high-value resources.

This separation reduces the radius of impact. In contexts such as financial servicesFor example, tracking, identity, and access controls need to be integrated. It's pointless to have a credential that's difficult to guess if, once discovered, it can do anything.

4. Automate rotation without disrupting integration.

Rotation cannot mean manually swapping a key on a Friday and hoping that no old application continues to use the previous one. OWASP describes the rotation This process can be automated through the creation, application, testing, and completion stages of the exchange. It allows for credential replacement without sacrificing security or availability.

After participating in an innovation event in Estonia, I returned with a question that I continue to use in product development: how to create systems that scale without turning security into bureaucracy? For API keys, automating the lifecycle is a concrete answer. A repetitive and sensitive process should not depend on someone's memory.

View this photo on Instagram

A post shared by Getulio Santos (@getuliosantos)

Stage	Action	Reduced risk
Create	Generate a new key with minimum permissions.	Reusing old credentials.
Apply	Distribute the new key only to authorized service centers.	Excessive exposure and sharing.
Test	Confirm authentication and core flows before disconnection.	Unavailable during the exchange.
Revoke	Invalidate the previous key after the transition.	Use of an old, compromised credential.

Herself - Host electronic signature This shows why availability and trust cannot be treated separately: a secure integration that breaks the user process is still a poorly designed integration.

5. Logs should show the incident without revealing the secret.

Useful logs record context, not the API key value. Credential identifier, calling service, time, endpoint, response status, authorized origin, latency, and correlation identifier already allow for much investigation. OWASP advises that API keys do not appear in URLs.Because they can end up being captured by web server logs. Headers are the most suitable place for this in many authentication flows.

Centralizing access logs, errors, and security events allows you to cross-reference signals that, in isolation, seem small. Repeated authentication failures may indicate a broken configuration, but also an attempt to use an old key. An unexpected spike in calls could be legitimate growth or abuse. Without context, the warning becomes mere noise.

Which alerts require a quick response?

Not every error requires opening an incident report. What deserves attention is the combination of frequency, origin, impact, and deviation from the known pattern.

• Sudden increase in 401 or 403 responses.
• Use of a revoked key or outside the expected transition window.
• Calls to endpoints that the service does not normally use.
• Volume spikes or a source incompatible with the authorized environment.
• Repeated failures immediately after a rotation.

KPIs transform key management into routine.

If a company only discovers that its API key policy has failed during an incident, there's a lack of management. Three simple indicators can help show if the process is functioning properly: expired or out-of-policy keys, key turnover time, and failed authentication rate. These indicators bring security closer to decisions about operation, cost, and continuity, something that also comes up when discussing security. digital product governance.

KPI	What to measure	Practical reading
Keys are expired.	Percentage of active credentials beyond the defined deadline.	It shows an accumulation of operating debt.
Rotation time	Time between request or incident and secure revocation of the old key.	It indicates actual reaction capacity.
Failed authentications	Failure rate by key, service, and period.	It helps detect incorrect configuration or anomalous usage.

Check out these related articles as well:

• Understand how the ZapSign API works in integrations.
• Learn about the role of liveness in KYC processes.
• See how API documentation organizes technical integration.

Protected API keys become operational discipline.

Properly storing credentials is only part of the job. A reliable architecture combines segregation, least privilege, rotation, revocation, observability, and incident response. When these controls are designed together, the company reduces its reliance on manual actions and can react without disrupting the user experience of the integration.

This is the result of a mature policy of API security It needs to deliver: less exposure, a smaller radius of impact, and a greater ability to quickly understand what happened. To extend this care to identity verification processes as well, Get to know the ZapSign ID..

Frequently Asked Questions (FAQ)