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

# Secrets

> Stored credentials that authorized Plays can use at runtime without keeping their values in source code.

Secrets store values that Play code needs to authenticate with another service.
Examples include a token for an application callback and the signing secret used to verify an incoming webhook.
The Play refers to a secret by name, such as `APP_CALLBACK_TOKEN`, while the workspace stores its value separately.

This separates a credential change from a source-code change.
An owner or admin can rotate a stored credential without placing the replacement value in a repository or agent prompt.
Deepline stores secret values encrypted and returns metadata through its management interfaces.

## Credentials and connections

Three resources have different purposes:

| Resource | Purpose |
| - | - |
| Deepline API key | Authenticates an application, CLI, or agent to Deepline with its authorized workspace access. |
| Provider connection | Lets Deepline tools use a connected provider account through a supported integration. |
| Play secret | Supplies a credential that custom Play code or a configured webhook verifier needs. |

A Play that calls a connected CRM tool usually uses the [integration's connection](https://deepline.com/docs/features/integrations.md).
Custom HTTP calls can use a Play secret for the destination's authentication.
Adding a Play secret does not create a provider connection or grant access at the external service.

## Workspace and Play scope

A workspace-scoped secret can serve several Plays in that workspace.
A Play-scoped secret applies to one named Play and can override a workspace secret with the same name.
For example, one Play can send callbacks to a different application account while other Plays use the shared credential.

An active Play override takes precedence.
When no active override exists, the workspace secret can apply.
An invalid active override produces an unavailable-secret error rather than silently selecting another credential.

The Play declares the secret names it needs.
Deepline checks that the run is authorized to resolve those names in its workspace and Play scope.
The supported runtime methods read the value or construct an authentication header for a request.
Secret-bearing HTTP requests require HTTPS.

## General use

Workspace owners and admins manage secret metadata and values in [Secrets](https://code.deepline.com/dashboard/integrations/secrets).
The CLI can also create or rotate supported secrets, check availability, and inspect metadata.
Interactive entry keeps values out of command arguments and shell history.

Management views show the name, scope, status, notes, and recorded usage metadata.
They do not reveal stored values.
A successful availability check establishes that a secret can resolve, not that the external service accepts the credential.

For a callback, the Play reads its declared token and sends an authenticated HTTP request.
The application receiving that request checks the token and records the result.
For an incoming signed webhook, the trigger's configured verifier uses its declared signing secret before admitting work.

## Rotation and disablement

Rotation replaces the active value for subsequent runtime resolution without changing the authorized secret name or scope.
It does not update a value that Play code already read or sent to another service.
Coordinate rotation with the service that issues or checks the credential.

Disabling a secret prevents it from resolving through its existing authorization.
Disabling a Play override can allow workspace fallback for a later launch.
Removing a value from Deepline does not revoke that credential at its provider.

Use narrow external permissions for each credential.
Play code receives a usable value, so source review still matters.
Keep secret values out of logs, returned results, datasets, and URLs.

## Related features and guides

* [Workspaces](https://deepline.com/docs/workspaces.md): members, roles, and API access.
* [Integrations](https://deepline.com/docs/features/integrations.md): provider accounts and supported credential forms.
* [Play triggers](https://deepline.com/docs/play-triggers.md): authenticated incoming events.
* [Play integration](https://deepline.com/docs/sdk-v2/production-integration.md): authenticated callbacks and destination writes.
* [SDK secret methods](https://deepline.com/docs/sdk-v2/sdk-reference.md#deepline-secrets-get-name): declaration and runtime contracts.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.