> ## Documentation Index
> Fetch the complete documentation index at: https://www.voiceflow.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate project API keys

> Use a personal key for development as yourself, or a service key for ongoing automation. The replacement uses a different identity and access model.

## Choose the replacement

Use a [personal key](/docs/developers/authentication/personal-keys) for development as yourself, or a [service key](/docs/developers/authentication/service-keys) for ongoing automation. The replacement uses a different identity and access model: it is not just a new string with the old key’s permissions.

This guide covers server-side integrations. Do not replace a browser widget credential with a personal or service key; use the widget’s installation instructions.

## Inventory the integration

List every application, environment, CI secret, and command that uses the old key. Record the endpoints and actions each integration needs. Confirm that the endpoints support the replacement credential before changing production. Keep the existing configuration available during verification.

## Switch and verify

<Steps>
<Step title="Create the replacement">

Follow the [personal-key](/docs/developers/authentication/personal-keys) or [service-key](/docs/developers/authentication/service-keys) setup. Select the necessary resources and actions.

</Step>
<Step title="Update a test configuration">

For the REST management API, send `Authorization: Bearer <replacement-key>`. For CLI, update `VF_TOKEN` or the configured credential source. Check for an explicit `--token` flag that could override the environment variable. Preserve the project and environment parameters.

</Step>
<Step title="Verify the integration">

Run a read-only request first, then test the actual required operation in an appropriate test project. A successful login or workspace listing does not prove permission to execute tools or publish.

</Step>
<Step title="Update the remaining consumers">

Roll out the verified configuration to each application and environment. Once every consumer is verified, retire the old key using its existing key-management controls.

</Step>
</Steps>

## Confirm the migration

Verify each application with the replacement credential and confirm that no deployment still references the old secret. Confirm the intended project, environment, and action permissions.

## Recover from rejected requests

<Accordion title="Requests fail after replacing the key">

If a request fails, check credential format, expiry, resource selection, and action permissions. Verify that this endpoint accepts the replacement credential. Keep the old key until verification is complete; do not broaden the replacement’s permissions solely to make an unrelated test command pass.

</Accordion>

## Continue building

[Permissions and scopes](/docs/developers/authentication/permissions) · [CLI authentication](/docs/cli/authentication) · [API quickstart](/docs/api-reference/quickstart)