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

​
What happens after you delete a key

Qonversion caches successful Secret Key checks to keep authentication fast, so revocation is not instantaneous. After you delete a key — in the dashboard or through the deprecated regenerate-secret endpoint — requests with it are normally rejected with 401 (control_unauthorized) within about an hour. A new key is not affected: it works on its first request.

​
What to do if a Secret Key has been exposed

Treat every Secret Key of the project as exposed, not only the one you know has leaked, and replace all of them:
1

Create a new Secret Key and move every consumer to it

Create the key in Settings → Developer → Secret keys, replace the old value everywhere it is stored, and verify the new key, as described in How to rotate a Secret Key without downtime.
2

Delete every older key

Delete all Secret Keys except the new one. Check the key list for keys that you or your team did not create, and delete those too.
3

Contact Qonversion support

Report the exposure to Qonversion support and name the affected project.

​
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. 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. This check prints only the HTTP status code, not the response body:
200 means the key works, and 401 (control_unauthorized) means it is not accepted. 403 (control_forbidden) means the key is recognized but the request is not allowed for this project — resolve that before you continue.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. Deletion cannot be undone; see What happens after you delete a key.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

Watch for authentication errors

For about an hour after deletion, the old key may still be accepted, so a quiet first few minutes do not prove that every consumer has switched. Keep watching your server logs for 401 (control_unauthorized) responses for at least an hour after deletion.

​
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 once revocation takes effect, whether or not you have updated it yet — see What happens after you delete a key;
  • every call rotates again: the endpoint does not honor an Idempotency-Key header, so never retry it automatically;
  • 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.