API keys: limit access and prepare for a leak

Least privilege, separate integration credentials, rotation and revocation: a practical way to manage API keys without losing operational control.

An integration can transfer orders correctly while retaining permission to delete the entire customer database. Successful requests rarely reveal excessive access. The consequences appear when a key leaks, a script behaves unexpectedly or a contractor leaves. Reviewing credentials therefore means examining what their compromise would allow, alongside the operations the integration actually needs.

Describe operations before issuing access

For each connection, list the objects it reads, the fields it changes and the actions it must never perform. An order-status service might need an identifier and permission to update a status. Customer exports, payments and user administration need separate justification. This is a design example, not a claim about a completed implementation.

AWS IAM guidance describes least privilege through actions, resources and conditions. That is a useful structure for an access contract: specify which records can be changed in which environment. If a provider offers only a broad API key, document that limitation. A gateway can narrow the interface available to its consumers, but the broad credential held by the gateway still needs protection.

Access reviews should include unusual paths, such as recovery scripts and support tools. A normal request trace may miss operations that run only during an incident. Removing permissions solely because they were unused last week can create a failure precisely when those tools are needed.

Give every credential an owner

A practical register records the purpose, system, environment, responsible person, consumers and revocation procedure. It should reference the credential without containing its value. Separate test and production access, and issue distinct credentials to independent integrations where the provider supports this. One process can then be disabled without interrupting every connection.

OWASP treats secrets as having a lifecycle that includes creation, rotation, revocation and expiration. This raises an operational question: who controls the credential after the project ends? Access issued through an employee's account needs an ownership arrangement that survives changes in the team.

Test the transition between keys

For a scheduled rotation, a possible sequence is to create replacement access, switch consumers, verify operations and revoke the previous credential. This depends on the provider allowing overlapping keys. Some APIs instead require a coordinated maintenance window. Document the actual mechanism rather than assuming a universal procedure.

A suspected leak changes the decision. Restricting abuse may matter more than uninterrupted service, so the team must review activity and decide whether a short interruption is acceptable. Removing a secret from source control does not revoke copies already obtained. Rotation is incomplete until the previous credential is confirmed unusable.

For deployment workflows, GitHub OIDC can exchange a job's identity for temporary cloud permissions. This reduces the need for a persistent cloud key in CI. Short token lifetime still leaves the role's permissions to review. Trust rules should identify the intended repository and deployment context; possession of a token alone is insufficient authorization.

Accept evidence, not a settings screenshot

Acceptance checks should exercise an allowed action, a forbidden action, a revoked credential and a rotation. Also inspect error messages, logs and diagnostic exports for secret disclosure. Useful audit records identify the access involved and the reason for rejection without recording the credential itself.

A product owner needs to know whether one compromised connection can be stopped and restored. A reasonable first stage includes a consumer map, constrained permissions and a rehearsed revocation procedure. A more elaborate secrets platform becomes useful when the team can maintain it and recover access during its own outage.

This review belongs in API integration planning. An initial discussion can use a connection inventory and required operations without sharing real keys.

Sources checked on 7 October 2026. The proposed checks and sequences are the author's engineering recommendations; available controls depend on the provider and environment.

A concrete starting point is my Dent-Picks work. I implemented synchronization between systems, including creation of a GoHighLevel lead after an incoming IVR call. That transition gives the access discussion specific operations, records and consequences if a connection stops. The public case does not document a credential-rotation procedure; the checks proposed in this article need a separate agreement.

In the guide to connecting documents, CRM and tasks, I start with data ownership and operation states. The same map helps define permissions for each step and identify who will restore pending work after access is revoked.