> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.qonversion.io/llms.txt
> Use this file to discover all available pages before exploring further.
# How to manage and rotate project keys
> Where to find the Qonversion Project key, API key, and Secret Keys, how to rotate a Secret Key without downtime (create a new key, migrate, verify, delete the old one), and why a deleted key can keep working for up to 1 hour.
Every Qonversion project has three kinds of keys. All of them live in the dashboard under **Settings → Developer** (in the **Developer tools** group), in the **Keys** section.
| Key | Format | Used for | Public? | Can be rotated in the dashboard? |
| --------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------------- |
| **Project key** | no prefix | Initializes the Qonversion SDK in your app; REST API v3 requests that do not need a Secret Key (for example, recording a purchase) | Yes — it ships inside your app | No |
| **API key** | no prefix | The Analytics API and store server notifications (Apple App Store Server Notifications, Google Real-time Developer Notifications) | No | No |
| **Secret Key** | `sk_` | Server-to-server access: every REST API v4 endpoint, privileged REST API v3 calls (grant / revoke entitlements). The [Qonversion MCP server](mcp-server) does **not** use Secret Keys — it authenticates with OAuth 2.1 | No — keep it on your server | Yes — create and delete, up to 10 per project |
A Secret Key grants full server-to-server access to the project. Store it only on your server or in your secret manager. **Never embed a Secret Key in an Android, iOS, or web app.**
## Where to find the keys in the dashboard
Open the [Qonversion dashboard](https://dash.qonversion.io), select the project, and go to **Settings → Developer**. The **Keys** section shows:
* **Project key** — read-only, with **Reveal** and **Copy** buttons.
* **API key** — read-only, with **Reveal** and **Copy** buttons.
* **Secret keys** — a table with the columns **Name**, **Key**, and **Created**, a counter such as "2 of 10", and a **Create secret key** button.
You can copy the full value of any Secret Key from the table at any time — it is not shown only once at creation. A key created before multiple keys were supported has no name and is listed as **Default**.
## Who can manage Secret Keys
Only team members with the **Admin** or **Manager** role can create or delete Secret Keys. Other roles that can open project settings see the list but not the **Create secret key** button or the delete action. See [Users and Access](users-and-access) for the role list.
## Secret Key limits and rules
| Rule | Value |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Maximum Secret Keys per project | `10` |
| Minimum Secret Keys per project | `1` — the last key cannot be deleted |
| Key name | Required when creating a key in the dashboard; up to 255 characters |
| Key prefix | `sk_` |
| All keys are equal | Every Secret Key of the project authenticates the same way; there is no "primary" key for authentication |
| A new key starts working | Immediately |
| A deleted key stops working | Within 1 hour |
| Where keys are created and deleted | In the dashboard — the REST API v4 has no endpoints to create, list, or delete individual Secret Keys; the only API that touches keys is the deprecated [`regenerate-secret`](#what-about-regenerate-secret) |
| Per-key usage ("last used") | Not shown — the dashboard does not tell you which key a request used |
## Why a deleted key keeps working for up to 1 hour
Qonversion's authentication layer caches the result of a key lookup on each API server for up to **1 hour**. Deleting or regenerating a key removes it from the database immediately, but the cache is **not** invalidated: an API server that has already accepted the old key keeps accepting it until its cached entry expires. So, after you delete a key:
* requests with the old key may still succeed for **up to 1 hour**, depending on which server handles them;
* after 1 hour, every request with the old key is rejected with `401` (`control_unauthorized`).
There is no way to revoke a key faster than this. If a key has leaked, delete it right away and treat it as usable by an attacker for the next hour.
A **new** key is never affected by the cache: failed lookups are not cached, so a newly created key authenticates on the very next request.
## How to rotate a Secret Key without downtime
Rotate by overlap: keep the old key working until every consumer has switched to the new one, then delete it.
In **Settings → Developer → Secret keys**, click **Create secret key**, enter a **Key name** that tells you where the key will be used (for example, `CI server` or `backend-prod-2026-09`), and click **Create**. The dialog shows the new `sk_…` value; copy it and click **Done**.
The new key works immediately. The old key keeps working, so nothing breaks yet. If the project already has 10 keys, **Create secret key** is disabled — delete an unused key first.
Replace the old key everywhere it is stored: server environment variables, your secret manager, CI/CD variables, and any scripts that call the REST API. MCP clients are not affected — the MCP server uses OAuth, not Secret Keys. Deploy or restart the services so they pick up the new value.
Make a request with the new key from each environment you migrated and check that it returns `200`:
```bash theme={null}
curl --request GET \
--url https://api.qonversion.io/v4/project-settings \
--header 'Authorization: Bearer sk_YOUR_NEW_SECRET_KEY'
```
The dashboard does not show which key a request used, so confirm the switch from your own configuration and logs before you continue.
In the Secret keys table, click the trash icon (**Delete secret key**) on the old key's row and confirm with **Delete**. The dialog warns: "Any server using it will lose access within 1 hour. This can't be undone."
You cannot delete the last remaining Secret Key — a project always keeps at least one. If the delete action is disabled, create the new key first.
The old key may keep authenticating for up to 1 hour after deletion (see [Why a deleted key keeps working for up to 1 hour](#why-a-deleted-key-keeps-working-for-up-to-1-hour)). If anything still uses it, it starts failing with `401` within that hour — watch your server logs for authentication errors during this window.
## What about `regenerate-secret`?
`POST /v4/project-settings/regenerate-secret` (and the MCP tool `regenerate_project_secret`) is **deprecated** — use the create-and-delete rotation above instead. The endpoint still works for existing integrations, but it rotates without an overlap:
* it creates a new Secret Key with the same name as the project's oldest key, **deletes that oldest key immediately**, and returns the new value as `secret_key`;
* every consumer still using the deleted key loses access within 1 hour, whether or not you have updated it yet;
* if the project has more than one Secret Key, the key it returns is the new one, while `GET /v4/project-settings` keeps reporting the oldest remaining key as `secret_key` — the two values can differ.
## How to rotate the Project key or the API key
You can't. The dashboard has no regenerate action for the **Project key** or the **API key**, and there is no API for it.
* The **Project key** is public by design: it is embedded in every copy of your app, so it is not a secret and does not need rotation.
* The **API key** authenticates store server notifications (App Store Server Notifications, Google Real-time Developer Notifications) and the Analytics API. If you believe it has been exposed, contact Qonversion support.
## Next steps
How to send the Secret Key with REST API v4 requests.
Read project configuration and store credentials over the API.
Connect AI agents to your project over OAuth 2.1 — no Secret Key needed.
Team roles and who can manage project settings.