---
id: KB-IN-003
url: https://app.codecontract.io/help/integrations/access-keys-and-how-to-look-after-them
idioma: en
categoria: integraciones
audiencia: desarrollador
nivel: intermedio
actualizado: 2026-08-13
tambienEn: [es]
relacionados: [KB-IN-002, KB-AD-002]
citadoPor: [KB-IN-005, KB-IN-012, KB-IN-016, KB-IN-018]
---

# Access keys: how not to get it wrong

_One per integration, out of the code, and rotated before you have to._

**Responde a:** create an api key · i pushed a key to github what now · rotate integration credentials · revoke an api key

An access key is a password no human types, and that is why it gets treated worse: it ends up in a repository, in a team chat, or in a script somebody copied. Three rules avoid nearly everything.

**En corto**

- One key per integration, never one shared between several.
- Never in the code and never in a message.
- With the minimum permission that integration needs, not all of them.

## One per integration

If the ERP and the time-tracking system share a key, revoking it because one was compromised takes down the other. With one each, you revoke what is affected and move on.

## Out of the code

In your system's environment variables, not in a file that gets committed. It is the commonest mistake and the worst to fix afterwards: deleting it from the code does not delete it from the history.

## If it has leaked

1. **Revoke it now** — Before investigating how it happened. A leaked key stops working the moment it is revoked.
2. **Create a new one and swap it** — In the system that was using it.
3. **Check what was done with it** — Accesses are logged. That is where you see whether anyone used it.

> [!IMPORTANT]
> Changing the key in the code without revoking the old one fixes nothing: the old one still works for whoever holds it. Revoking is the step that counts.

> [!NOTE]
> Rotating periodically even when nothing has happened turns rotation into a familiar chore rather than an emergency on the day it matters.

**Do they expire on their own?**

They can be given an expiry, and it is a good idea.

**Can I see a key after creating it?**

No. It is shown once; if lost, create another.

**How many can I have?**

As many as you need. Many narrow keys beat one with every permission.

## Ejemplos

**A developer finds a key was left in a public repository two weeks ago.**

- Revokes it immediately
- Creates a new one and puts it in environment variables
- Reviews the access log for those two weeks

→ Confirms it was never used from outside and the incident closes in twenty minutes.

**The API key is shared over messaging between three people and ends up on a supplier's phone.**

- Creates one key per integration, not per person
- Revokes the one that circulated and issues a new one

→ Each connection has its own key, and revoking it breaks nothing else.

**The key is hard-coded by somebody who no longer works there.**

- Stores keys in the secret manager, not in code
- Rotates the key when the person leaves

→ A developer leaving stops being a security incident.

**A key grants access to everything when the integration reads two fields.**

- Gives each key the minimum scope it needs

→ A leaked key exposes two fields rather than the whole archive.

**Nobody knows which keys are active or what for.**

- Checks the list and notes what each one is for

→ The unused ones can be withdrawn.

**A key has not been rotated in three years.**

- Sets a rotation schedule with advance warning

→ Rotation happens calmly rather than after a scare.