# API keys and secrets

> Keep private keys private while still using them in your app.

Some services need a private key: a mapping provider, an SMS gateway, an AI model. Those keys are dangerous in the wrong place, and easy to put there by accident.

## The rule

A secret belongs on the server. Your browser code should never contain a key that can spend money or read private data. Anything that ships to the browser can be read by anyone who opens developer tools.

## Adding a secret

Ask the builder to add a secret. It will give you a secure place to enter the value, never the chat itself. Then tell it the name of the key and what it is for:

```
Use the secret MAPS_API_KEY in a server function that returns
the driving distance between two postcodes.
```

The key is kept on the server side and used only by server code. The app calls your own endpoint; the key is never sent to the browser.

## What still counts as public

Some values are designed to be public and are safe in the browser:

- Your payment provider's publishable key
- Analytics identifiers
- Your project's public address

Knowing the difference is what matters. If a value would cost you money or expose someone's data, it is a secret.

## When a key leaks

Rotate it. A leaked key is replaced, not hidden: create a new one with the provider, replace the stored secret, then revoke the old one.

> [!warning] Never paste a private key into the chat as part of a description. Add it as a secret and refer to it by name.

## Common mistake to avoid

Building a feature against a test key and forgetting to change it before publishing. Before you go live, check that every connected service is using live credentials, and that the test ones are gone.