Globals and Environment-Specific Secrets
Use ordinary global values and server-only secrets in Twidget. Add and replace dummy secrets, reference them in a server workflow and verify Dev/Prod separation.
Watch tutorial (6:01)
Use ordinary global values and server-only secrets in Twidget. Add and replace dummy secrets, reference them in a server workflow and verify Dev/Prod separation.
Watch tutorial (6:01)Keep shared configuration and private values in one place. Open Global at the top of an endpoint, function or event, or open the manager from Settings. The Variables and Secrets tabs belong to the selected workspace.
Use ordinary variables for reusable settings such as a default page size or service address. Use secrets for private values such as an external service's API key. Secret names can be selected in server workflows, but their saved values are never shown in the manager.
The Variables tab keeps the familiar typed editor. Add a field, choose its type, enter its value and save. Existing workflows continue to use references such as $global.default_page_size.
These values remain editable configuration. Hiding a text field on screen does not make it a protected secret. Keep credentials in Secrets instead. Changing a value during a workflow does not save a new workspace setting; edit the manager when you want to change the saved configuration.
Check the workspace name and Dev/Prod badge before entering a value.
Open Secrets and choose Add secret. The editor opens above the list, using the same name and value fields as other variables.
Enter a descriptive name, such as SERVICE_KEY. Use letters, numbers and underscores, beginning with a letter or underscore.
Enter the value and save. You can also save a name without a value to prepare it for later configuration.
A confirmation appears in the bottom notification bar after saving or removing a secret.
The list shows whether the secret is configured, together with its update time. It never displays the saved value, and there is no reveal button. A secret name stays the same after creation so existing workflow references remain clear. To use a different name, create a new secret and update the affected workflows.
Each workspace can hold up to 100 secrets. A value can contain up to 16 KiB of text. Do not paste a private value into the name, a workflow label or an ordinary variable.
The list shows configured values as Set and a prepared name without a value as Not set.
Choose Replace to enter a new value. The replacement field starts empty; leaving it empty keeps the saved value. After saving, the new value is available to subsequent runs without publishing every workflow again. A run that has already started continues with the values it loaded.
Use Remove when you intend to remove a secret, then confirm the change. A workflow that still requires it will need attention. Removing all ordinary globals does not remove secrets.
If another person changes the secret while you are editing, refresh its latest details before replacing it. Temporary values are cleared when you leave the editor or switch workspaces; enter the replacement again if needed. Only members allowed to manage the workspace can change its secrets.
Replacement starts with an empty value field. Leaving it blank keeps the saved value.
Choose a secret from the variable selector in a server workflow. References use $secrets.SERVICE_KEY; the ordinary variable prefix remains $global.
Select a secret by name without revealing its value. This example compares a test input with a workspace secret.
For example, select the secret as the value for an external service's authorization header. Keep the value out of the endpoint's response. Secrets are available to server workflows, including endpoints, functions, middleware and events. They are not available to browser/page workflows.
A secret without a configured value cannot satisfy a workflow that requires it. Configure it in that workspace before testing or enabling the workflow. Test runs use their selected workspace's secrets even when database records are isolated; an isolated test does not automatically select development credentials.
Give the same secret name different values in your existing Dev and Prod workspaces. For example, Dev can use a service's test key while Prod uses its live key. References remain the same, but each run resolves the selected workspace's own value. There is no fallback to another workspace.
Secrets do not need an extra workspace and do not increase your workspace limit. If your account is already at its limit, use an existing permitted test workspace. Changing a workspace's Dev/Prod label does not move, replace or choose a second set of secret values.
Secret values are not copied between workspaces, included in release comparisons or restored by rollback. A release checks that required secret names have configured values in its destination. Add or configure missing secrets there, then review the release again. A rollback restores workflow definitions while retaining the destination's current secrets.
Release review lists missing names so you can configure them in the destination before trying again. Values stay hidden.
Saved secret values stay hidden in management screens and are redacted from supported logs, traces and test diagnostics. This does not make every authored workflow safe: an endpoint can deliberately send a secret or a transformed value in its response or an external request. Review the fields you send and return, use sample keys when testing and replace a key if it is exposed.
Useful guides: Workspaces, Testing, Safer releases, Send an external request.
Test suites
Test a customer journey across several endpoints in a single ordered run. For example: sign in, create an order, retrieve it, then check its status. Every run shares its own isolated database across its steps. Your workspace records are not changed by those database actions. This version supports is...
Variables
Variables are essential building blocks in Twidget that allow you to store and manipulate data dynamically within your no-code applications. They enable you to create flexible and interactive applications by holding values that can be changed and referenced throughout your workflow. Creating Variabl...
Inputs
Overview. In Twidget, inputs are essential elements that allow you to configure endpoints and functions. Events do not use inputs. Endpoint Inputs. Endpoint inputs are used to retrieve data from requests. The available types of endpoint inputs are: 1. Path: Variables that are part of the URL path. 2...
Command Output
Some commands in Twidget return outputs, which are essential for dynamic and conditional logic within your workflows. These outputs are displayed next to the command and are prefixed with an "as" to indicate the variable name. Using Output Variables. Once a command returns an output, you can use the...
Data Types
Twidget supports six main data types to facilitate interactions within the platform. These data types are essential for defining inputs, outputs, and table fields, helping users understand the nature of the data being handled. The available data types in Twidget are as follows: Text. - Description: ...