Skip to main content
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.
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, 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 for the role list.

​
Secret Key limits and rules

​
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.
1

Create a new Secret Key

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.
2

Migrate every consumer to the new key

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.
3

Verify the new key

Make a request with the new key from each environment you migrated and check that it returns 200:
The dashboard does not show which key a request used, so confirm the switch from your own configuration and logs before you continue.
4

Delete the old key

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.
5

Wait up to 1 hour

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). 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

REST API v4 authentication

How to send the Secret Key with REST API v4 requests.

Project Settings API

Read project configuration and store credentials over the API.

Qonversion MCP server

Connect AI agents to your project over OAuth 2.1 — no Secret Key needed.

Users and Access

Team roles and who can manage project settings.