You pushed an API key to GitHub. What should you do next?

Your portfolio project is finally working. You push the code to GitHub, send someone the link, then notice that the file includes a credential for the service you used.

An API key is a credential software uses to access a service. An application programming interface, or API, lets software communicate with another system. Depending on its permissions, a leaked key can allow someone else to use resources or access information.

The useful response is a sequence: stop the credential working, understand its exposure, clean up the project and improve the way it stores credentials. This guide walks through a fictional example without using any real secrets.

Why deleting the line is only part of the job

Git records earlier versions of your files in commits, which are snapshots of a project. Removing a key from the current file does not automatically remove it from that history. Copies may also exist elsewhere. GitHub recommends revoking or rotating an exposed secret first.

GitHub Docs: removing sensitive data from a repository

In October 2026, GitHub described improvements to its secret-detection model. Scanning can help people discover exposure, but your response still needs an owner and a plan.

GitHub: secret-detection research, 13 October 2026

A fictional leak: the weather-widget project

Meet the example

Noor builds a portfolio page that displays weather information. She uses a service key during development and accidentally includes it in a public repository. She notices the mistake after sharing the repository link with a mentor.

The example does not establish that anyone has misused the key. Noor still needs to treat its secrecy as lost. Her first job is to prevent that particular credential from authorising further requests.

Work through the response

1. Revoke the exposed credential

Purpose: Stop the old credential authorising new requests.

Open the service provider’s genuine account dashboard through a trusted route. Find its instructions for revoking the credential or replacing it safely. Rotation means issuing a replacement and retiring the old credential. Make sure the old one is actually invalidated.

For a work project, notify the responsible developer or security team immediately and follow their incident process. Coordinate any replacement that could interrupt a running service. Do not paste the secret into a chat asking for help.

GitHub Docs: keeping API credentials secure

2. Understand what it could access

Purpose: Establish the scope of exposure and any signs of use.

Record the service, permissions, repository visibility and approximate exposure period. Review the provider’s available usage records and billing or access activity. Avoid assuming a quiet dashboard proves nobody obtained the key.

In Noor’s example, the key’s permitted operations and provider records determine what she needs to investigate. A useful report names what is known and what still needs checking.

3. Clean the repository with support

Purpose: Remove sensitive material without damaging collaborators’ work.

Follow GitHub’s guidance for removing sensitive data. Rewriting history changes commit identifiers and can affect other people’s copies, so coordinate it with collaborators rather than force-pushing an improvised fix.

History clean-up does not recall a credential from someone who already copied it. Revocation and repository clean-up address different parts of the problem.

GitHub Docs: removing sensitive data from a repository

Check where the replacement belongs

GitHub’s credential guidance recommends secure storage and limited permissions. Keep secrets out of source files and use the storage mechanism appropriate to the environment, such as encrypted workflow secrets.

GitHub Docs: keeping API credentials secure

A useful distinction for portfolio projects

A value delivered to someone’s browser is accessible to that visitor, even if it began in an environment variable. Do not put a secret server credential into browser code and assume the variable name hides it. Use the provider’s documented browser-safe approach or a properly protected server component.

Before adding a credential, ask: does this service expect the value to be public, what restrictions support that use, and where will the value actually be delivered?

Try the exposure worksheet

Fill this in using dummy information

For Noor, the completed worksheet is more useful than “I deleted it”. It describes the retired key, outstanding checks and the change she will make before the next deployment.

Credential purpose: what operation does it authorise?
Exposure: which files, commits, screenshots or shared notes included it?
Containment: who can revoke it, and how will you confirm that happened?
Impact: which records need reviewing?
Replacement: where will the new credential be stored?
Prevention: what check will run before the next share?

Before you share your next project

Review staged changes, use dummy values in examples and check your provider’s credential-storage guidance. Enable relevant scanning or protection features where available, and understand their coverage.

Make the immediate next step small: choose one project and identify every credential it uses, who owns it and how you would revoke it. Do that without copying the actual secret into your notes.

Sources and reading: Checked 14 October 2026. The scenarios and exercises in this article are fictional.