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:
A Play that calls a connected CRM tool usually uses the integration’s connection.
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. 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: members, roles, and API access.
- Integrations: provider accounts and supported credential forms.
- Play triggers: authenticated incoming events.
- Play integration: authenticated callbacks and destination writes.
- SDK secret methods: declaration and runtime contracts.