Update a workflow variable

Anything written directly into a workflow's params is visible to everyone who can view workflows and is returned by GET /v1/workflows. Variables keep secrets and environment-specific values out of the document. Each variable belongs to exactly one workflow, so two workflows that need the same token each hold their own copy. A workflow whose trigger or steps reference a variable reports containsVariables: true.

Steps read a variable by its ID, not its name: /#variables.<variableId> in a param, or {{{variables.<variableId>}}} inside a template, for example in an Authorization header of a REST step. The ID is the 24-character id returned when you create the variable; a reference that uses the name resolves to nothing. Variables are removed from the run context that failed-run records store, so their values don't leak into error logs.

Values are write-only

Because the value can't be read back, keep the source of truth in your own secret store and write it to Kustomer when it changes. Workflows copied to another workflow or org don't bring their variables with them: create them again on the copy, then update every variable reference to the new IDs.

Which endpoint to use

Creating a variable needs name, value and type; PUT changes only the fields you send, so you can rotate a secret by sending just value. Variables are cached, so a new or changed value can take about a minute to reach new runs, just like workflow edits. When you create a workflow that depends on variables, create it disabled, add the variables, then enable it, so no run starts without them.