> For the complete documentation index, see [llms.txt](https://infinitode-docs.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://infinitode-docs.gitbook.io/documentation/api-documentation/keeping-your-api-key-safe.md).

# Keeping your API key safe

How to keep your standard API key safe, whether you call our APIs from a browser, a server, or a serverless function — plus how to reset a leaked key yourself and review your last 30 days of API calls

Browser calls to our API work: every endpoint allows cross-origin requests, so you *can* call it straight from a web page. But anything in front-end code is public. Your standard API key spends your monthly allowance and any calls you've bought, so keep it on a server.

**Recommended:**

* **Production:** your front end calls your own backend (a server, or a serverless function on Netlify, Vercel, Cloudflare and so on). The backend adds the key and calls Infinitode. Keep the key in an environment variable, never in your repository.
* **Testing:** use the [API playground](/documentation/api-documentation/api-playground.md). Mock mode returns dummy data in the real response shape and needs no key at all, and live mode sends a real request when you want real output.
* **Leaked key?** [Reset it yourself](#reset-a-leaked-key-yourself) from your account page — up to 3 times in a rolling seven-day window (verified email and a recent sign-in required). Then check [your call history](#see-what-your-keys-were-used-for) to see what was done with it.

Example: a Netlify Function proxy

```javascript
// netlify/functions/bmi.js (your site, not ours)
export default async (request) => {
  const { height, weight } = await request.json();
  const response = await fetch("https://infinitode.netlify.app/api/v1/bmi", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.INFINITODE_API_KEY}`,
    },
    body: JSON.stringify({ height, weight }),
  });
  return new Response(await response.text(), {
    status: response.status,
    headers: { "Content-Type": "application/json" },
  });
};
```

Your page then calls `/.netlify/functions/bmi` with no key at all.

{% hint style="warning" %}
Revealing your keys, buying a pack, enrolling an authenticator app and resetting a key all require a **verified email address**. If your account page is hiding your keys, verify your email first — see [What email verification unlocks](/documentation/account-security-billing.md#what-email-verification-unlocks).
{% endhint %}

***

## :repeat: Reset a leaked key yourself

You no longer need to wait on support to replace a key. On your account page, your API key has a **Reset** button, and you can use it up to **3 times in a rolling seven-day window**. A reset requires a **verified email address** and a **recent sign-in**.

1. Open your account page and find the key you want to replace.
2. Press **Reset**. The new key takes the old one's place on the page.
3. Copy the new key into your server's environment variable, then redeploy.

{% hint style="warning" %}
The old key is invalidated **immediately**, with no grace period. From the moment you press **Reset**, any request using the old key returns `401` with `"Invalid API key."` — so update every place that used the old key first, or your app fails on its next call.
{% endhint %}

* **The limit is 3 resets per rolling seven-day window** — a safety measure on our side, not a quota to use up. Keep some in reserve so that if something ever leaks, you can swap the key yourself in seconds instead of waiting. If you genuinely run out, contact support and we'll sort it out.
* **Your balance is unaffected:** plan, allowances and bought calls stay as they are. Calls already spent with the leaked key — including bought calls — can't be restored.
* **Your history survives the reset.** Calls made with the old key stay in [your call history](#see-what-your-keys-were-used-for), so a reset doesn't hide what happened.

***

## :mag: See what your keys were used for

Your account page lists every call made with your key for the **last 30 days**. Use it to work out what happened after a leak, to find a deployment you forgot about, or to see where your allowance actually went. Filter the history by **time**, navigate it with the **chart** on the page, and **export** what you see as **CSV or JSON** — up to **5,000 entries** are returned per query, so narrow the time filter for a busy account.

Each entry shows:

| Field         | What it tells you                                                                                    |
| ------------- | ---------------------------------------------------------------------------------------------------- |
| Date and time | When the call was made                                                                               |
| API           | Which endpoint the call hit, e.g. `/api/v1/bmi`                                                      |
| Method        | Whether it was a `POST` or a `GET` call                                                              |
| Key used      | The **final three characters** of the key, when available, and whether that key was still **active** |
| Status        | The response status and the **result category**, with the error message for calls that failed        |
| Origin        | An approximate **country and city**, and the **origin or referrer** the request came from            |
| Call used     | Whether that request counted against your calls                                                      |

The entry fields vary a little between calls: not every request carries an origin or referrer, and location is approximate rather than a precise address.

* **Errors are listed too.** A `400`, `405` or `429` was rejected before your key was accepted, and it's marked as not using a call — see [Error responses](/documentation/api-documentation.md#error-responses).
* **Every call is in one list,** whether it came from your own code, a serverless function or the API playground's live mode.
* **The 30 days is a rolling window.** Entries older than 30 days are deleted automatically, so copy out anything you need to keep before then.
* **Only call metadata is recorded.** The history stores the facts listed above — not your request parameters, not the output the API returned, and not your raw IP address. A leaked key's history is safe to screenshot or send to support.
* **Need totals rather than individual calls?** Your remaining monthly allowance, your plan's allowance and any bought calls are shown on the same account page. Mock requests in the API playground don't use any of them.

{% hint style="info" %}
Call history is only visible to you, on your account page. It isn't an API endpoint, and other users of the platform can't see it.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://infinitode-docs.gitbook.io/documentation/api-documentation/keeping-your-api-key-safe.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.