Skip to main content

SDK Key Generation and Management

SDK keys are environment-specific credentials used to connect a client application or backend service to a PlayServ project.

In practice, an SDK key is generated in the Backoffice and then used in the SDK or server configuration of the application that needs access to the project. A single project can contain multiple keys, which makes it possible to support different applications, workflows, and key rotation scenarios.

This guide explains what SDK keys are, where they are managed, and how key creation, editing, regeneration, and deletion affect existing integrations.

What SDK keys are​

An SDK key is a credential associated with a specific project and environment.

It is used during SDK integration so the client or backend can authenticate with the correct PlayServ project. In simple terms, the key tells the SDK which project it should connect to and which environment it should use.

SDK keys should be treated as sensitive credentials.

note

SDK keys are environment-specific. A key created for Development should be used only in Development workflows, and a key created for Production should be used only in Production workflows.

Why a project can have multiple SDK keys​

A project can contain more than one SDK key.

This is useful in several common scenarios:

  • different applications need separate credentials
  • one key is used for local development and another for QA or automated testing
  • a key needs to be rotated without immediately breaking an existing workflow
  • a temporary key is needed for a specific build, contractor, or integration

Using multiple keys makes access management more flexible and reduces the need to reuse the same credential everywhere.

Where to find SDK keys​

SDK keys are generated and managed from the project workspace.

On this page you will typically see:

  • a Quick Start Panel with links to setup resources
  • an SDK Keys Summary table listing the keys available for the selected environment

This is the main area used to review existing keys and manage them.

SDK Keys Summary table in the project workspace

Before you create or change a key​

Because SDK keys are environment-specific, each key belongs to a particular environment.

Keep Development and Production keys separate. If you are working on testing, staging, or local setup, use Development. Production keys should be reserved for live releases and production services.

warning

Treat SDK keys like passwords. Do not share them in tickets, screenshots, chat messages, or public repositories. Store them in a secure location.

Create a new SDK key​

Creating a key adds a new credential for the selected project environment.

This is useful when:

  • a new client needs its own key
  • a backend service should use a separate credential
  • QA or automation should not reuse the same key as local development
  • an older key should be replaced gradually rather than all at once

When creating a key, the Backoffice asks for:

  • a key name
  • the target environment

The key name is used to help identify the credential later in the keys table. A clear name makes the table much easier to manage once the project contains several keys.

Create SDK key form with name and environment fields

After the key is generated, store it safely.

note

The full key value may only be shown once at the moment of creation. Save it immediately before closing the success state or confirmation dialog.

SDK key creation success state showing the new key value

Edit an SDK key​

Editing a key updates its label or descriptive metadata.

This is useful when the key itself is still valid, but its current name no longer clearly describes how it is used.

Editing a key does not replace the secret value. It only helps keep the key list understandable for the team.

Edit SDK key dialog

note

Use Edit when the key should stay active but needs a clearer or more accurate label.

Regenerate an SDK key​

Regenerating a key replaces its secret value while keeping the key entry itself.

This is the right action when:

  • you suspect the key was exposed
  • you want to rotate credentials
  • you want to replace an old secret without removing the key entry from the project
warning

Regenerating a key invalidates the previous value. Any application or service still using the old key must be updated.

Regenerate SDK key confirmation dialog

After regeneration, the Backoffice shows the new value. That new secret should be copied immediately and updated everywhere the previous value was used.

Regenerate SDK key success state showing the new key value

Delete an SDK key​

Deleting a key removes it from the project completely.

This should only be done when the key is no longer needed by any active workflow, application, or service.

warning

After deletion, any application or service still using that key will no longer be able to authenticate.

Delete SDK key confirmation dialog

Before deleting a key, make sure it is no longer used by:

  • active builds
  • backend services
  • automation flows
  • internal tools
  • team members still testing with that credential

Best practices​

A few habits make SDK key management much easier over time:

  • use clear, descriptive names
  • avoid sharing one key across unrelated integrations
  • keep Development and Production keys separate
  • rotate keys if exposure is suspected
  • remove unused keys to reduce clutter and risk
  • store keys securely instead of keeping them in plain text files or chats
tip

A project with several well-named keys is easier to manage than a project where one shared key is reused everywhere.

SDK keys first appear during project creation in Creating a New Project.

Once the required key is available, the next step is to use it during integration, which is covered in Connecting a Project to Unity.