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

# Credential management

> How Deck Vault tokenizes, stores, and deletes user credentials.

When you [store a credential](/concepts/credentials), Deck tokenizes it into Deck Vault. How credentials are managed after storage depends on your integration.

You have two options: keep credentials in Deck Vault for automatic reuse, or delete the credential to permanently remove them.

## Deck Vault

By default, Deck stores credentials in Deck Vault. Storage is built on tokenization: each secret value is placed in an isolated vault and replaced with a token, and Deck's application database holds the tokens, never the secrets. Credentials never leave the vault except to authenticate a session, and each set is scoped to a single source. They are never shared across users, organizations, or sources.

With credentials stored, you get:

* **Automatic re-authentication.** When a session expires, Deck attempts to re-authenticate from the stored credentials. Most of the time the user doesn't notice, though some sources prompt for MFA, which pauses the run for an [interaction](/guides/interactions). [Credential persistence](/concepts/credentials#credential-persistence) can reduce repeat MFA prompts by reusing saved login state, where the source honors it.
* **Persistent credentials.** Users link their account once and it works until they revoke access.
* **Zero-friction task runs.** Scheduled and on-demand tasks authenticate silently.

## How Deck Vault protects credentials

Deck Vault swaps secrets for tokens the moment a credential is written. Deck's database and API responses carry tokens in place of secrets.

* **Tokenized at write.** Secret values such as passwords are vaulted on every credential, on every plan, before the credential is saved. If vaulting fails, nothing is stored. The vault is isolated from the rest of Deck, and a secret is only ever resolved back to run a task. The [`tokenized` array](/concepts/credentials#tokenizing-source-fields) extends the same protection to source fields.
* **Never logged.** Secret values are scrubbed from log output, including on error paths, and automated leak tests guard the code paths that handle secrets.
* **Never returned by the API.** Reading a credential returns a masked summary: the non-secret identifier (such as username) and which fields are set, never the stored secret values. No endpoint returns a stored secret.
* **Encrypted in transit.** All traffic to and from Deck, including vault calls, is encrypted with TLS.
* **Removed on delete.** Deleting a credential permanently removes its stored secrets (see [Removing credentials](#removing-credentials)).

## Saved login state

With [credential persistence](/concepts/credentials#credential-persistence) enabled, Deck also stores the credential's login state (cookies and device trust) between runs so sources that honor it can skip the login flow. Saved login state gets the same level of protection as the credentials themselves:

* **Encrypted at rest.** Saved login state is encrypted with AES-256-GCM under its own dedicated key. The key is held in the same isolated vault as credential secrets and is only resolved to run a task. It is never logged.
* **Never returned by the API.** The API exposes only whether persistence is enabled, never the saved state itself.
* **Destroyed on disable or delete.** Turning persistence off or deleting the credential destroys the encryption key, permanently and irreversibly rendering the saved state unreadable.
* **Expires automatically.** Saved state that hasn't been refreshed by a run in 45 days is destroyed the same way.

## Removing credentials

To permanently delete credentials from Deck Vault, [delete the credential](/concepts/credentials):

```text theme={null}
DELETE /v2/credentials/{credential_id}
```

This permanently and irreversibly removes the credentials from Deck Vault, along with any [saved login state](#saved-login-state). The credential transitions to `deleted` status. The credential object and its task runs remain queryable, but it can no longer authenticate any task runs. If the user needs access again, create a new credential.

## Choosing an approach

The right choice depends on how your users interact with connected sources and how sensitive the credentials are.

|                          | Deck Vault (default)                     | Terminate after use                               |
| ------------------------ | ---------------------------------------- | ------------------------------------------------- |
| **User experience**      | Store once, use indefinitely             | Re-enter credentials each time                    |
| **Session recovery**     | Automatic re-authentication              | Requires a new credential                         |
| **Operational overhead** | Low. Deck manages authentication.        | Higher. Your app handles re-linking flows.        |
| **Best for**             | Recurring tasks, long-lived integrations | One-time operations, high-sensitivity credentials |

## Terminating after a one-time extraction

Some use cases only need a single extraction, like importing a year of transaction history. After the task run completes, delete the credential to remove it from Deck Vault:

```text theme={null}
DELETE /v2/credentials/{credential_id}
```

Task run output and stored files remain available. Only the credentials are removed.